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Мир очень сильно изменился с того момента, когда первое издание этой книги уви¬ 
дело свет в 1992 году. Компьютерные сети и распределенные системы всех типов 
стали обычным делом. Теперь маленькие дети бродят по Интернету там, где рань¬ 
ше можно было встретить только компьютерных профессионалов. В результате эта 
книга также претерпела существенные изменения. 

Самое заметное изменение заключается в том, что первое издание этой книги 
было наполовину посвящено однопроцессорным операционным системам и на¬ 
половину — распределенным системам. Я выбрал такой формат в 1991 году, пото¬ 
му что в те годы далеко не во всех университетах был специальный курс по рас¬ 
пределенным системам, и все, что студенты должны были узнать о распределенных 
системах, следовало вместить в курс по операционным системам, для которого 
и предназначалась эта книга. Теперь в большинстве университетов есть отдель¬ 
ный курс по распределенным системам, поэтому необходимости комбинировать 
эти два предмета в одном курсе и одной книге больше нет. Эта книга предназнача¬ 
ется для первого курса по операционным системам и поэтому фокусируется в ос¬ 
новном на традиционных однопроцессорных системах. 

Я являюсь соавтором двух других книг по операционным системам, и с их уче¬ 
том возможны два цикла курсов. 

Практически ориентированный цикл: 

1. Разработка и реализация операционных систем. 

2. Распределенные системы. 

Традиционный цикл: 

1. Современные операционные системы. 

2. Распределенные системы. 

В первом учебном цикле используется операционная система МШІХ и пред¬ 
полагается, что студенты будут экспериментировать с системой МШІХ в соответ¬ 
ствующей лаборатории, предоставляемой первому курсу. Во втором учебном цик¬ 
ле операционная система МШІХ не используется. Вместо нее предоставляются 
небольшие симуляторы, которые могут использоваться студентами для упражне¬ 
ний во время первого курса с использованием данной книги. Эти симуляторы мож¬ 
но найти на \ѵеЬ-странице автора по адресу Ні1р://ѵѵш/.с5.ѵи.пІ/~а5І/, если щелк¬ 
нуть мышью по ссылке БоИѵѵаге апсі зирріетепіагу таіегіаі Іог ту Ьоок$. 

Помимо главного изменения, заключающегося в переключении акцента книги 
на однопроцессорные операционные системы, другие существенные изменения 
состоят в добавлении целых глав по компьютерной безопасности, мультимедийным 
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операционным системам и 'ѴѴіпсІохѵв 2000, представляющих собой важные и свое¬ 
временные вопросы. Кроме того, была добавлена новая уникальная глава по про¬ 
ектированию операционных систем. 

Другая новая особенность этой книги состоит в том, что во многие главы те¬ 
перь добавлены разделы, посвященные исследованиям по теме данной главы. Это 
сделано с целью познакомить читателя с современными трудами по процессам, 
управлению памятью и т. д. Разделы содержат многочисленные ссылки на совре¬ 
менную исследовательскую литературу для заинтересованных читателей. Кроме 
того, в главе 13 содержится множество ссылок на учебную литературу. 

Наконец, к этой книге было добавлено множество разделов, а многие разделы 
были серьезно пересмотрены. Это разделы по темам: графические интерфейсы 
пользователя, мультипроцессорные операционные системы, управление энерго¬ 
потреблением для переносных компьютеров, надежные системы, вирусы, сетевые 
терминалы, файловые системы для компакт-дисков, КАШ, мягкие таймеры, ста¬ 
бильные хранилища, справедливое планирование и новые алгоритмы замещения 
страниц. Добавлено множество новых задач и многие старые задачи были пере¬ 
смотрены. Общее количество задач теперь превышает 450. Сборник задач с реше¬ 
ниями может быть предоставлен профессорам, использующим эту книгу на своем 
курсе. Они могут получить копию книги у своего локального представителя изда¬ 
тельства РгепНсе Наіі. Кроме того, было добавлено более 250 новых ссылок на но¬ 
вейшую литературу, чтобы привести книгу в соответствие с современностью. 

Несмотря на удаление из книги более чем 400 страниц старого материала, кни¬ 
га увеличилась в размерах благодаря добавлению нового. Книга все еще годится 
для семестрового курса или курса, состоящего из двух четвертей, но, вероятно, 
слишком длинна для курса из одной четверти или одного триместра большинства 
университетов. По этой причине при написании этой книги была предусмотрена 
ее модульная структура. Любой курс по операционным системам должен вклю¬ 
чать главы с 1 по 6. Это базовый материал, который должен знать каждый студент. 

При наличии дополнительного времени можно изучить дополнительные гла¬ 
вы. Каждая из них предполагает, что читатель уже ознакомился с первыми шес¬ 
тью главами, но сами главы с 7 по 12 являются самодостаточными, поэтому может 
использоваться любое подмножество этих глав и в любом порядке, в зависимости 
от интересов преподавателя. По мнению автора, главы с 7 по 12 значительно инте¬ 
реснее первых шести глав книги. Преподаватели должны сказать своим студен¬ 
там, что тем придется съесть капусту, прежде чем они смогут получить двойную 
порцию торта с фальшивым шоколадом на десерт. 

Я хотел бы поблагодарить тех людей, кто оказал мне помощь в пересмотре час¬ 
тей рукописи. Среди них Рида Бацци (Шба Ваггі), Риккардо Беттати (Кіссагбо 
ВеПаіі), Фелипе Кабрера (Реііре СаЬгега), Ричард Чэпман (КісЬагй СЬаршап), 
Джон Коннели ОоЬп Соппеіу), Джон Дикинсон (,|о1т Піскіпвоп), Джон Элиот 
ОоЬп ЕШоП), Дебора Фринке (ПеЬогаЬ Ргіпске), Чандана Гамидж (СЬапбапа 
Саша§е), Роберт Гайст (КоЬЬегІ Сеіві), Дэвид Голде (Паѵісі СоЫв), Джим Гриф¬ 
фин (}іт СгіДіоеп), Гари Харкин (Сагу Нагкіп), Франс Кашук (Егапв КаавЬоек), 
Муккай Кришнамурти (Миккаі КгівЬпашоогіЬу), Моника Лэм (Мопіса Баш), 
Джусси Лейво (.Іивві Ьеі\ѵо), Херб Майер (НегЬ Мауег), Кирк МакКьюзик (Кігк 
МсКизіск), Эви Немет (Еѵі ИешеШ), Билл Потвин (ВШ Роіѵіп), Прасант Шеной 
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(Ргазапі ЗЬепоу), Томас Скиннер (ТЬотаз Зкіппег), Сиан-Хе Сун (Хіап-Не Зип), 
Вилльям Терри (\Ѵі11іат Теггу), Робберт Ван Ренессе (КоЪЬегІ Ѵап Кепеззе) и Ма- 
артен ван Стеен (Маагіеп ѵап Зіееп). Джеми Ханрахан (Датіе НапгаЬап), Марк 
Русинович (Магк КиззіпоѵісЬ) н Дэйв Соломон (Эаѵе Зоіотоп) невероятно мно¬ 
го знали о \Уіпбо\ѵз 2000 и очень мне помогли. Особые благодарности следует вы¬ 
разить Элу Вудхаллу (А1 \Ѵоос1Ьи11) за ценные обзоры и мысли о многих новых 
проблемах, перечисляемых в конце главы. 

Мои студенты также очень помогли мне своими комментариями и своей не¬ 
посредственной реакцией, особенно Стаас де Йонг (Зіааз бе боп§)> Ян де Вое (Дап 
бе Ѵоз), Нильс Дрост (№е1з Бгозі), Давид Фоккема (Оаѵіб Роккета), Ауке Фоль- 
кертс (Айке Роікепз), Петер Грюневеген (Реіег Сгоепе\ѵе@еп), Вилько Ибес (\Уі1со 
ІЪез), Стефан Янсен (Зіеіап бапзеп), Йерун Кетема (бегоеп Кеіета), Юри Мулдер 
(боегі Миібег), Ирвин Оппенхайм (Іпѵіп ОррепЬеіт), Стеф Пост (5іе( Розі), Умар 
Реман (ІІтаг КеЬтап), Даниель Рийкхоф (Оапіеі КукЬо(), Маартен Зандер 
(Маагіеп Запбег), Мориц ван дер Шее (Маигііз ѵап бег ЗсЬее), Рик ван дер Стул 
(Клк ѵап бег Зіоеі), Марк ван Дрил (Магк ѵап Вгіеі), Деннис ван Вейн (Бептз ѵап 
Ѵееп) и Томас Зееман (ТЬотаз 2еетап). 

Барбара (ВагЬага) и Марвин (Магѵіп), как всегда, чудесны, каждый своим не¬ 
повторимым образом. Наконец, но не в последнюю очередь, я бы хотел поблагода¬ 
рить Сьюзан (Зигаппе) за ее любовь и терпение, не говоря уже обо всех фруктах, 
которыми она меня потчевала. 


Эндрю С. Таненбаум (Апйгею 5. ТапепЬашп) 




Глава 1 

Введение 


Современная компьютерная система состоит из одного или нескольких процессо¬ 
ров, оперативной памяти, дисков, клавиатуры, монитора, принтеров, сетевого ин¬ 
терфейса и других устройств, то есть является сложной комплексной системой. 
Написание программ, которые следят за всеми компонентами, корректно исполь¬ 
зуют их и при этом работают оптимально, представляет собой крайне трудную 
задачу. По этой причине компьютеры оснащаются специальным уровнем программ¬ 
ного обеспечения, называемым операционной системой. Операционная система 
отвечает за управление всеми перечисленными устройствами и обеспечивает 
пользователя имеющими простой, доступный интерфейс программами для рабо¬ 
ты с аппаратурой. Эти системы составляют предмет данной книги. 

Расположение операционной системы в общей структуре компьютера показа¬ 
но на рис. 1.1. Внизу находится аппаратное обеспечение, которое во многих случа¬ 
ях само состоит из двух или более уровней (или слоев). Самый нижний уровень 
содержит физические устройства, состоящие из интегральных микросхем, провод¬ 
ников, источников питания, электронно-лучевых трубок и т. п. То, как они устро¬ 
ены и как работают, относится к сфере деятельности инженеров, специалистов по 
электронике. 


| Программы-приложения 


Системные программы 


Оборудовение, апперетура 


Рис. 1.1. Компьютерная система состоит из аппаратного обеспечения, 
системных программ и приложений 

Выше расположен микроархитектурный уровень, на котором физические уст¬ 
ройства рассматриваются с точки зрения функциональных единиц. Обычно на 
этом уровне находятся внутренние регистры центрального процессора (СРІІ — 
Сепігаі Ргосез5Іп§ ІІпіІ) и арифметико-логическое устройство. На каждом такте 
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процессора из регистра выбирается один или два операнда, которые обрабатывают¬ 
ся в арифметико-логическом устройстве (например, действием операции сложения 
или логического И). Результат сохраняется в одном или нескольких регистрах. 
В некоторых машинах операции над данными контролируются программными 
приложениями, которые называются микропрограммами. В других компьютерах 
такой контроль выполняется напрямую аппаратными цепями. 

Определенная система команд передается по маршруту передачи данных. Не¬ 
которые команды могут быть выполнены за один цикл передачи данных, другие 
требуют нескольких циклов. Такие команды могут использовать регистры или 
другие возможности аппаратуры. Команды, видимые для работающего на ассемб¬ 
лере программиста, формируют уровень ІЗА (ІпзігисСіоп 5еС АгсЬкесШге — архи¬ 
тектура системы команд), часто называемый машинным языком. 

Обычно машинный язык содержит от 50 до 300 команд, служащих преимуще¬ 
ственно для перемещения данных по компьютеру, выполнения арифметических 
операций и сравнения величин. Управление устройствами на этом уровне осуще¬ 
ствляется с помощью загрузки определенных величин в специальные регистры 
устройств. Например, диску можно дать команду чтения, записав в его регистры 
адрес места на диске, адрес в основной памяти, число байтов для чтения и направле¬ 
ние действия (чтение или запись). На практике нужно передавать большее количе¬ 
ство параметров, а статус операции, возвращаемый диском, достаточно сложен. 
Кроме того, при программировании многих устройств ввода-вывода (І/О — ІприС/ 
Оійриі) очень важную роль играют временные соотношения. 

Операционная система предназначена для того, чтобы скрыть от пользователя 
все эти сложности. Она состоит из уровня программного обеспечения, который 
частично избавляет от необходимости общения с аппаратурой напрямую, вместо 
этого предоставляя программисту более удобную систему команд. Действие чте¬ 
ния блока из файла в этом случае представляется намного более простым, чем ког¬ 
да нужно заботиться о перемещении головок диска, ждать, пока они установятся 
на нужное место и т. д. 

Над операционной системой на нашем рисунке расположены остальные сис¬ 
темные программы. Здесь находятся интерпретатор команд (оболочка), системы 
окон, компиляторы, редакторы и т. д. Важно понимать, что подобные программы 
не являются частью операционной системы, хотя обычно поставщики компьютеров 
устанавливают их на машины. Это очень важное замечание. Под операционной 
системой обычно понимается то программное обеспечение, которое запускается 
в режиме ядра или, как его еще называют, режиме супервизора. Она защищена 
от вмешательства пользователя с помощью аппаратных средств (мы не рассмат¬ 
риваем в данный момент некоторые старые микропроцессоры, которые вообще не 
имеют аппаратной защиты). Компиляторы и редакторы запускаются в пользова¬ 
тельском режиме. Если пользователю не нравится какой-либо компилятор, он при 
желании может написать свой собственный, но он не может написать собствен¬ 
ный обработчик прерываний системных часов, являющийся частью операционной 
системы и обычно защищенный аппаратно от попыток его модифицировать. 

Существуют системы, в которых это различие размыто. К ним относятся встро¬ 
енные системы, они могут не иметь режима ядра, или интерпретируемые системы, 
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подобные основанным на ^ѵа операционным системам, в которых для разделения 
компонентов используется интерпретация, а не оборудование. Но в традиционных 
компьютерах операционная система представляет собой набор программ, запус¬ 
кающихся в режиме ядра. 

Во многих системах есть программы, которые работают в пользовательском 
режиме, но помогают операционной системе или выполняют специализированные 
функции. Например, часто встречаются программы, позволяющие пользователям 
изменять свои пароли. Они не являются частью операционной системы и запус¬ 
каются не в режиме ядра, но выполняемые ими функции влияют на работу систе¬ 
мы, и такие программы должны быть определенным способом защищены от воз¬ 
действия пользователя. 

В некоторых системах части того, что обычно считалось операционной системой 
(например, файловая система), работают в пространстве пользователя. В таких 
системах сложно провести четкую границу. Понятно, что все программы, запуска¬ 
ющиеся в режиме ядра, является частью операционной системы, но некоторые 
программы, работающие вне этого режима, могут также относится к операцион¬ 
ной системе, или, по крайней мере, тесно с ней связаны. 

Наконец, над системными программами расположены прикладные программы. 
Обычно они покупаются или пишутся пользователем для решения собственных 
проблем — обработки текста, электронных таблиц, технических расчетов или сохра¬ 
нения информации в базе данных. 


Что такое операционная система? 

Большинство пользователей компьютеров имеют некоторый опыт общения с опе¬ 
рационной системой, но обычно они испытывают затруднения при попытке дать 
определение операционной системы. В известной степени проблема связана с тем, 
что операционные системы выполняют две основные, но практически не связан¬ 
ные между собой функции: расширение возможностей машины и управление ее 
ресурсами. И в зависимости от того, какому пользователю вы зададите вопрос, вы 
услышите в ответ больше или об одной функции, или о другой. Давайте рассмот¬ 
рим обе функции. 

Операционная система как расширенная машина 

Как было упомянуто ранее, архитектура (система команд, организация памя¬ 
ти, ввод-вывод данных и структура шин) большинства компьютеров на уровне 
машинного языка примитивна и неудобна для работы с программами, особенно 
в процессе ввода-вывода данных. Чтобы это утверждение не показалось голослов¬ 
ным, кратко рассмотрим пример того, как происходит ввод-вывод данных с гибкого 
диска через совместимые микросхемы контроллера ИЕС РЭ765, используемые 
на большинстве персональных компьютеров с процессором Іпіеі. (В этой книге 
мы будем использовать и термин «гибкий диск», и термин «дискета».) Контрол¬ 
лер РЭ765 имеет 16 команд, каждая задается передачей от 1 до 9 байт в регистр 
устройства. Это команды для чтения и записи данных, перемещения головки дис- 
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ка и форматирования дорожек, а также для инициализации, распознавания, уста¬ 
новки в исходное положение и калибровки контроллера и приводов. 

Основными командами являются команды геасі и ѵѵгііе (чтение и запись). Каж¬ 
дая из них требует 13 параметров, упакованных в 9 байт. Эти параметры опреде¬ 
ляют такие элементы, как адрес блока на диске, который нужно прочитать, коли¬ 
чество секторов на дорожке, физический режим записи, расстановку промежутков 
между секторами. Они же сообщают, что делать с меткой адреса данных, которые 
были удалены. Если вы не можете сразу это осмыслить, не волнуйтесь — полнос¬ 
тью это понятно лишь посвященным. Когда выполнение операции завершается, 
чип контроллера возвращает упакованные в 7 байт 23 параметра, отражающие на¬ 
личие и типы ошибок. Но этого не достаточно, и программист при работе с гибким 
диском должен также постоянно знать, включен двигатель или нет. Если двига¬ 
тель выключен, его следует включить (с длительным ожиданием запуска) прежде, 
чем данные будут прочитаны или записаны. Двигатель не может оставаться вклю¬ 
ченным слишком долго, так как гибкий диск изнашивается. Программист вынуж¬ 
ден выбирать между длинными задержками во время загрузки и изнашивающи¬ 
мися гибкими дисками (с вероятностью потери данных на них). 

Даже если не вдаваться глубже в подробности этого процесса, становится ясно, 
что обыкновенный программист вряд ли захочет столкнуться с такими деталями 
при работе с гибким диском (или жестким диском, работа с ним не менее сложна). 
Вместо этого программисту нужны простые высокоуровневые абстракции. В слу¬ 
чае работы с дисками типичной абстракцией является коллекция именованных 
файлов, содержащихся на диске. Каждый файл может быть открыт для чтения или 
записи, прочитан или записан, а потом закрыт. А такие детали, как текущее состоя¬ 
ние двигателя или использование при записи модифицированной частотной моду¬ 
ляции, не должны содержаться в абстракции, предстающей перед пользователем. 

Программа, скрывающая истину об аппаратном обеспечении и представляю¬ 
щая простой список поименованных файлов, которые можно читать и записывать, 
и является операционной системой. Операционная система не только устраняет 
необходимость работы непосредственно с дисками и предоставляет простой, ориен¬ 
тированный на работу с файлами интерфейс, но и скрывает множество неприятной 
работы с прерываниями, счетчиками времени, организацией памяти и другими 
элементами низкого уровня. В каждом случае абстракция, предлагаемая операци¬ 
онной системой, намного проще и удобнее в обращении, чем то, что может предло¬ 
жить нам непосредственно основное оборудование. 

С точки зрения пользователя операционная система выполняет функцию рас¬ 
ширенной машины или виртуальной машины, в которой проще программировать 
и легче работать, чем непосредственно с аппаратным обеспечением, составляющим 
реальный компьютер. То, каким образом операционная система достигает своей 
цели — долгая история, но мы подробно рассмотрим этот процесс в нашей книге. 
Подведем итог вышесказанному: операционная система предоставляет нам ряд 
возможностей, которые могут использовать программы с помощью специальных 
команд, называемых системными вызовами. Мы приведем примеры наиболее об¬ 
щих системных вызовов далее в этой главе. 
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Операционная система как менеджер ресурсов 

Концепция, рассматривающая операционную систему прежде всего как удобный 
интерфейс пользователя, — это взгляд сверху вниз. Альтернативный взгляд, снизу 
вверх, дает представление об операционной системе как о механизме, присутству¬ 
ющем в устройстве компьютера для управления всеми частями этой сложнейшей 
машины. Современные компьютеры состоят из процессоров, памяти, датчиков 
времени, дисков, мыши, сетевого интерфейса, принтеров и огромного количества 
других устройств. В соответствии со вторым подходом работа операционной сис¬ 
темы заключается в обеспечении организованного и контролируемого распреде¬ 
ления процессоров, памяти и устройств ввода-вывода между различными про¬ 
граммами, состязающимися за право их использовать. 

Представьте, что случилось бы, если бы на одном компьютере оказались рабо¬ 
тающими три программы и все они одновременно попытались бы напечатать свои 
выходные данные на одном и том же принтере. Возможно, первые несколько строк 
на листе появились бы от первой программы, следующие несколько — из второй 
программы, затем бы следовало несколько строк от третьей программы и т. д. В ре¬ 
зультате получилась бы полная неразбериха. Операционная система наводит по¬ 
рядок в подобных ситуациях, буферизируя на диске все данные, предназначенные 
для печати. В процессе работы программы операционная система сохраняет ее 
выходные данные на диске во временном файле. Затем, по окончании работы этой 
программы, система отправляет данные на принтер, в то время как другая програм¬ 
ма может продолжать формировать свои выходные данные, не обращая внимания 
на то, что они пока еще фактически не посылаются на печатающее устройство. 

Когда компьютером (или сетью) пользуются несколько пользователей, необхо¬ 
димость в управлении памятью, устройствами ввода-вывода, другими ресурсами 
и их защите сильно возрастает, поскольку пользователи могут обращаться к ним 
в абсолютно непредсказуемом порядке. К тому же часто приходится распределять 
между пользователями не только оборудование, но и информацию (файлы, базы 
данных и т. д.). С этой точки зрения основная задача операционной системы за¬ 
ключается в отслеживании того, кто и какой ресурс использует, в обработке зап¬ 
росов на ресурсы, в подсчете коэффициента загрузки и разрешении проблем кон¬ 
фликтующих запросов от различных программ и пользователей. 

Управление ресурсами включает в себя их мультиплексирование (распределе¬ 
ние) двумя способами: во времени и в пространстве. Когда ресурс распределяется 
во времени, различные пользователи и программы используют его по очереди. 
Сначала один из них получает доступ к использованию ресурса, потом другой и т. д. 
Например, несколько программ хотят обратиться к центральному процессору. 
В этой ситуации операционная система сначала разрешает доступ к процессору 
одной программе, затем, после того как она поработала достаточное время, другой 
программе, затем следующей и, в конце концов, опять первой. Определение того, 
как долго ресурс будет использоваться во времени, кто будет следующим и на 
какое время ему предоставляется ресурс — это задача операционной системы. Еще 
один пример временного мультиплексирования — распределение заданий, посы¬ 
лаемых для печати на принтер. Когда задания выстраиваются в очередь для печати 
на одном принтере, операционной системе каждый раз нужно принимать решение 
о том, которое из них будет печататься следующим. 
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Другой вид распределения — это пространственное мультиплексирование. 
Вместо поочередной работы каждый клиент получает часть ресурса. Обычно опе¬ 
ративная память разделяется между несколькими работающими программами, так 
что все они одновременно могут постоянно находиться в памяти (например, исполь¬ 
зуя центральный процессор по очереди). Если предположить, что памяти дос¬ 
таточно для того, чтобы хранить несколько программ, эффективнее разместить 
в памяти сразу несколько программ, чем выделить всю память одной программе, 
особенно если ей нужна лишь небольшая часть имеющейся памяти. Конечно, при 
этом возникают проблемы справедливого распределения, защиты памяти и т. д., 
и для разрешения подобных вопросов существует операционная система. Другой 
ресурс, распределяемый пространственно, — это диск (жесткий). Во многих систе¬ 
мах один диск в одно и то же время может содержать файлы нескольких пользова¬ 
телей. Распределение дискового пространства и отслеживание того, кто какие бло¬ 
ки диска использует, является типичной задачей управления ресурсами, которую 
также выполняет операционная система. 


История операционных систем 

История развития операционных систем насчитывает уже много лет. В следую¬ 
щих разделах книги мы кратко рассмотрим некоторые основные моменты этого 
развития. Так как операционные системы появились и развивались в процессе 
конструирования компьютеров, то эти события исторически тесно связаны. Поэто¬ 
му чтобы представить, как выглядели операционные системы, мы обсудим следу¬ 
ющие друг за другом поколения компьютеров. Такая схема взаимосвязи поколе¬ 
ний операционных систем и компьютеров довольно груба, но она обеспечивает 
некоторую структуру, без которой ничего не было бы понятно. 

Первый настоящий цифровой компьютер был изобретен английским матема¬ 
тиком Чарльзом Бэббиджем (СЬагІез ВаЪЪа§е, 1792-1871). Хотя большую часть 
жизни Бэббидж посвятил попыткам создания своей «аналитической машины», он 
так и не смог заставить ее работать должным образом. Это была чисто механичес¬ 
кая машина, а технологии того времени не были достаточно развиты для изготов¬ 
ления многих деталей и механизмов высокой точности. Не стоит и говорить, что 
его аналитическая машина не имела операционной системы. 

Интересный исторический факт: Бэббидж понимал, что для аналитической 
машины ему необходимо программное обеспечение, поэтому он нанял молодую 
женщину по имени Ада Лавлейс (Аба Боѵеіасе), дочь знаменитого британского 
поэта Лорда Байрона. Она и стала первым в мире программистом, а язык програм¬ 
мирования Аба® назван в ее честь. 

Первое поколение (1945-55): электронные 
лампы и коммутационные панели 

После неудачных попыток Бэббиджа вплоть до Второй мировой войны в конст¬ 
руировании цифровых компьютеров не было практически никакого прогресса. 
Примерно в середине 1940-х Говард Айкен (Но\ѵагб Аікеп) в Гарварде, Джон 
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фон Нейман ОоЬп ѵоп Ыешпапп) в Институте углубленного изучения в Принсто¬ 
не, Дж. Преспер Эккерт у. Ргезрег Ескегі), Вильям Мочли (\Уі11іат МаисЫеу) 
в Пенсильванском университете, Конрад Цузе (КопгасІ 2ше) в Германии и мно¬ 
гие другие продолжили работу в направлении создания вычислительных машин. 
На первых машинах использовались механические реле, но они были очень медли¬ 
тельны, длительность такта составляла несколько секунд. Позже реле заменили 
электронными лампами. Машины получались громоздкими, заполняющими целые 
комнаты, с десятками тысяч электронных ламп, но все равно они были в миллионы 
раз медленнее, чем даже самый дешевый современный персональный компьютер. 

В те времена каждую машину и разрабатывала, и строила, и программировала, 
и эксплуатировала, и поддерживала в рабочем состоянии одна команда. Все програм¬ 
мирование выполнялось на абсолютном машинном языке, управления основными 
функциями машины осуществлялось просто при помощи соединения коммутаци¬ 
онных панелей проводами. Тогда еще не были известны языки программирования 
(даже ассемблера не было). Об операционных системах никто и не слышал. Обыч¬ 
ный режим работы программиста был таков: записаться на определенное время на 
специальном стенде, затем спуститься в машинную комнату, вставить свою комму¬ 
тационную панель в компьютер и провести несколько следующих часов в надеж¬ 
де, что во время работы ни одна из двадцати тысяч электронных ламп не выйдет 
из строя. Фактически тогда на компьютерах занимались только прямыми числовы¬ 
ми вычислениями, например расчетами таблиц синусов, косинусов и логарифмов. 

К началу 50-х, с выпуском перфокарт, установившееся положение несколько 
улучшилось. Стало возможно вместо использования коммутационных панелей 
записывать и считывать программы с карт, но во всем остальном процедура вы¬ 
числений оставалась прежней. 

Второе поколение (1955-65): транзисторы 
и системы пакетной обработки 

В середине 50-х изобретение и применение транзисторов радикально изменило 
всю картину. Компьютеры стали достаточно надежными, появилась высокая ве¬ 
роятность того, что машина будет работать довольно долго, выполняя при этом 
полезные функции. Впервые сложилось четкое разделение между проектировщи¬ 
ками, сборщиками, операторами, программистами и обслуживающим персоналом. 

Машины, теперь называемые мэйнфреймами, располагались в специальных 
комнатах с кондиционированным воздухом, где ими управлял целый штат профес¬ 
сиональных операторов. Только большие корпорации, правительственные учреж¬ 
дения или университеты могли позволить себе технику, цена которой исчислялась 
миллионами долларов. Чтобы выполнить задание (то есть программу или комп¬ 
лект программ), программист сначала должен был записать его на бумаге (на Фор¬ 
тране или ассемблере), а затем перенести на перфокарты. После этого — принести 
колоду перфокарт в комнату ввода данных, передать одному из операторов и идти 
пить кофе в ожидании, когда будет готов результат. 

Когда компьютер заканчивал выполнение какого-либо из текущих заданий, 
оператор подходил к принтеру, отрывал лист с полученными данными и относил 
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его в комнату для распечаток, где программист позже мог его забрать. Затем опе¬ 
ратор брал одну из колод перфокарт, принесенных из комнаты ввода данных, и счи¬ 
тывал их. Если в процессе расчетов был необходим компилятор языка Фортран, 
то оператору приходилось брать его из картотечного шкафа и загружать в машину 
отдельно. Из-за одного только хождения операторов по машинному залу впустую 
терялась масса драгоценного компьютерного времени. 

Если учитывать высокую стоимость оборудования, не удивительно, что люди 
довольно скоро занялись поиском способа повышения эффективности использо¬ 
вания машинного времени. Общепринятым решением стала система пакетной 
обработки. Первоначально замысел состоял в том, чтобы собрать полный поднос 
заданий (колод перфокарт) в комнате входных данных и затем переписать их на 
магнитную ленту, используя небольшой и (относительно) недорогой компьютер, 
например, ІВМ 1401, который был очень хорош для считывания карт, копирова¬ 
ния лент и печати выходных данных, но не подходил для числовых вычислений. 

Другие, более дорогостоящие машины, такие как ІВМ 7094, использовались для 
настоящих вычислений. Это изображено на рис. 1.2. 




е 


Рис. 1.2. Ранняя система пакетной обработки: программист приносит карты для ІВМ 1401 (а); 
ІВМ 1401 записывает пакет заданий на магнитную ленту (б); оператор приносит входные 
данные на ленте к ІВМ 7094 (в); ІВМ 7094 выполняет вычисления (г); оператор переносит 
ленту с выходными данными наІВМ 1401 (д); ІВМ 1401 печатает выходные данные (е) 


Примерно после часа сбора пакета заданий лента перематывалась, и ее относили 
в машинную комнату, где устанавливали на лентопротяжном устройстве. Затем опе¬ 
ратор загружал специальную программу (прообраз сегодняшней операционной 
системы), которая считывала первое задание с ленты и запускала его. Выходные 
данные записывались на вторую ленту вместо того, чтобы идти на печать. Завер¬ 
шив очередное задание, операционная система автоматически считывала с ленты 
следующее и начинала обрабатывать его. После обработки всего пакета оператор 
снимал ленты с входной и выходной информацией, ставил новую ленту со следу¬ 
ющим заданием, а готовые данные помещал на ІВМ 1401 для печати в автоном¬ 
ном режиме (то есть без связи с главным компьютером). 

Структура типичного входного задания показана на рис. 1.3. Оно начиналось 
с карты $_|ОВ, на которой указывалось максимальное время выполнения задания 
в минутах, загружаемый учетный номер и имя программиста. Затем поступала карта 
8ЕОКТКАН дающая операционной системе указание загрузить компилятор языка 
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Фортран с системной магнитной ленты. Эта карта следовала за программой, ко¬ 
торую нужно было компилировать, а после нее шла карта $ЬОАБ, указывающая 
операционной системе загрузить только что скомпилированную объектную про¬ 
грамму. (Скомпилированные программы часто записывались на временных лентах, 
данные с которых могли стираться сразу после использования, и их загрузка долж¬ 
на была выполняться явно.) Следом шла карта $ШЖ с данными, дающая операци¬ 
онной системе команду выполнять программу. Наконец, карта завершения $ЕКБ 
отмечала конец задания. Эти примитивные управляющие перфокарты были пред¬ 
шественниками современных языков управления и интерпретаторов команд. 

Большие компьютеры второго поколения использовались главным образом для 
научных и технических вычислений, таких как решение дифференциальных урав¬ 
нений в частных производных, часто встречающихся в физике и инженерных зада¬ 
чах. В основном на них программировали на языке Фортран и ассемблере, а типич¬ 
ными операционными системами были РМ5 (Рогігап Мопйог Бузіет) и ІВ5У5 
(операционная система, созданная корпорацией ІВМ для компьютера ІВМ 7094). 



Третье поколение (1965-1980): интегральные 
схемы и многозадачность 

К началу 60-х годов большинство изготовителей компьютеров имело две отдельные, 
полностью несовместимые производственные линии. С одной стороны, существо¬ 
вали научные крупномасштабные компьютеры с пословной обработкой текста 
типа ІВМ 7094, использовавшиеся для числовых вычислений в науке и технике. 
С другой стороны — коммерческие компьютеры с посимвольной обработкой, та¬ 
кие как ІВМ 1401, широко используемые банками и страховыми компаниями для 
сортировки и печатания данных. 
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Развитие и поддержка двух совершенно разных производственных линий для 
изготовителей были достаточно дорогим удовольствием. Кроме того, многим поку¬ 
пателям изначально требовалась небольшая машина, однако позже ее возможнос¬ 
тей становилось недостаточно и требовался более мощный компьютер, который 
работал бы с теми же самыми программами, но быстрее. 

Фирма ІВМ попыталась решить эти проблемы разом, выпустив серию машин 
ІВМ/360. 360-е были серией программно-совместимых машин, варьирующихся от 
компьютеров размером с ІВМ 1401 до машин, значительно более мощных, чем 
ІВМ 7094. Эти компьютеры различались только ценой и производительностью 
(максимальным объемом памяти, быстродействием процессора, количеством раз¬ 
решенных устройств ввода-вывода и т. д.). Так как все машины имели одинако¬ 
вую структуру и набор команд, программы, написанные для одного компьютера, 
могли работать на всех других (по крайней мере, в теории). Кроме того, 360-е были 
разработаны для поддержки как научных (то есть численных), так и коммерчес¬ 
ких вычислений. Одно семейство машин могло удовлетворить нужды всех поку¬ 
пателей. В последующие годы, используя более современные технологии, корпо¬ 
рация ІВМ выпустила компьютеры, совместимые с 360, эти серии известны под 
номерами 370, 4300, 3080 и 3090. 

360-е стали первой основной линией компьютеров, на которой использовались 
мелкомасштабные интегральные схемы, дававшие преимущество в цене и качестве 
по сравнению с машинами второго поколения, созданными из отдельных транзисто¬ 
ров. Корпорация ІВМ добилась мгновенного успеха, а идею семейства совместимых 
компьютеров скоро приняли и все остальные основные производители. В компь¬ 
ютерных центрах до сих пор можно встретить потомков этих машин. В настоящее 
время они часто используются для управления огромными базами данных (напри¬ 
мер, для систем бронирования и продажи билетов на авиалиниях) или как серве¬ 
ры узлов Интернета, которые должны обрабатывать тысячи запросов в секунду. 

Основное преимущество «одного семейства» оказалось одновременно и вели¬ 
чайшей его слабостью. По замыслу его создателей все программное обеспечение, 
включая операционную систему 05/360, должно было одинаково хорошо рабо¬ 
тать на всех моделях компьютеров: и в небольших системах, которые часто заме¬ 
няли 1401-е и применялись для копирования перфокарт на магнитные ленты, и на 
огромных системах, заменяющих 7094-е и использовавшихся для расчета прогно¬ 
за погоды и других сложных вычислений. Кроме того, предполагалось, что одну 
операционную систему можно будет использовать в системах как с несколькими 
внешними устройствами, так и с большим их количеством; а также как в коммер¬ 
ческих, так и в научных областях. Но самым важным было, чтобы это семейство 
машин давало результаты независимо от того, кто и как его использует. 

Ни ІВМ, ни кто-либо еще не мог написать программного обеспечения, удов¬ 
летворяющего всем этим противоречивым требованиям. В результате появилась 
огромная и необычайно сложная операционная система, примерно на два или три 
порядка превышающая по величине РМ5. Она состояла из миллионов строк, на¬ 
писанных на ассемблере тысячами программистов, содержала тысячи и тысячи 
ошибок, что повлекло за собой непрерывный поток новых версий, в которых пы¬ 
тались исправить эти ошибки. В каждой новой версии устранялась только часть 
ошибок, вместо них появлялись новые, так что общее их число, вероятно, остава¬ 
лось постоянным. 
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Один из разработчиков 05/360, Фред Брукс (Ртеб Вгоокз), впоследствии на¬ 
писал остроумную и язвительную книгу с описанием своего опыта работы с 05/ 
360. Мы не можем здесь дать полную оценку этой книги, но достаточно будет ска¬ 
зать, что на ее обложке изображено стадо доисторических животных, увязших в 
яме с дегтем. Обложка книги [302] демонстрирует похожую точку зрения на опе¬ 
рационные системы, бывшие динозаврами в мире компьютеров. 

Несмотря на свои огромные размеры и недостатки, 05/360 и подобные ей 
операционные системы третьего поколения, созданные другими производителя¬ 
ми компьютеров, на самом деле достаточно неплохо удовлетворяли требованиям 
большинства клиентов. Они даже сделали популярными несколько ключевых тех¬ 
нических приемов, отсутствовавших в операционных системах второго поколения. 
Самым важным достижением явилась многозадачность. На компьютере ІВМ 7094, 
когда текущая работа приостанавливалась в ожидании операций ввода-вывода 
с магнитной ленты или других устройств, центральный процессор просто бездей¬ 
ствовал до окончания операции ввода-вывода. При сложных научных вычисле¬ 
ниях и ограниченных возможностях процессора устройства ввода-вывода задей¬ 
ствовались довольно редко, так что это потраченное впустую время не играло 
существенной роли. Но при коммерческой обработке данных время ожидания ус¬ 
тройства ввода-вывода могло занимать 80 или 90 % всего рабочего времени, по¬ 
этому необходимо было что-нибудь сделать во избежание длительного простаива¬ 
ния весьма дорогостоящего процессора. 

Решение этой проблемы заключалось в разбиении памяти на несколько частей, 
называемых разделами, каждому из которых давалось отдельное задание, как по¬ 
казано на рис. 1.4. Пока одно задание ожидало завершения работы устройства вво¬ 
да-вывода, другое могло использовать центральный процессор. Если в оператив¬ 
ной памяти содержалось достаточное количество заданий, центральный процессор 
мог быть загружен почти на все 100 % по времени. Множество одновременно хра¬ 
нящихся в памяти заданий требовало наличия специального оборудования для 
защиты каждого задания от возможного любопытства и ущерба со стороны осталь¬ 
ных заданий. 360-я и другие системы третьего поколения были снабжены подоб¬ 
ными аппаратными средствами. 


Разделы 

памяти 


Рис. 1.4. Многозадачная система с тремя заданиями в памяти 

Другим важным плюсом операционных систем третьего поколения стала 
способность считывать задание с перфокарт на диск по мере того, как их приноси¬ 
ли в машинный зал. Всякий раз, когда текущее задание заканчивалось, операци¬ 
онная система могла загружать новое задание с диска в освободившийся раздел 
памяти и запускать его. Этот технический прием называется «подкачкой» данных 
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или спулингом (зроо1іп§, это английское слово произошло от аббревиатуры 
Зітиііапеоиз РегірЬегаІ Орегайоп Оп Ілпе — совместная периферийная операция 
в интерактивном режиме) и его также используют для выдачи полученных дан¬ 
ных. С появлением подкачки стали больше не нужны 1401-е и исчезли многократ¬ 
ные переносы магнитных лент. 

Хотя операционные системы третьего поколения вполне подходили для боль¬ 
ших научных вычислений и справлялись с крупными коммерческими обработка¬ 
ми данных, они все еще, по существу, представляли собой разновидности системы 
пакетной обработки. Многие программисты тосковали по первому поколению ма¬ 
шин, когда они могли распоряжаться всей машиной в течение нескольких часов 
и имели возможность быстро отлаживать свои программы. При системах третьего 
поколения временной промежуток между передачей задания и возвращением ре¬ 
зультатов часто составлял несколько часов, так что единственная неуместная 
запятая могла стать причиной сбоя при компиляции, и получалось, что програм¬ 
мист тратил впустую половину дня. 

Желание сократить время ожидания ответа привело к разработке режима раз¬ 
деления времени, варианту многозадачности, при котором у каждого пользовате¬ 
ля есть свой диалоговый терминал. Если двадцать пользователей зарегистрирова¬ 
ны в системе, работающей в режиме разделения времени, и семнадцать из них 
думают, беседуют или пьют кофе, то центральный процессор по очереди предо¬ 
ставляется трем пользователям, желающим работать на машине. Так как люди, от¬ 
лаживая программы, обычно выдают короткие команды (например, компилиро¬ 
вать процедуру на пяти страницах 1 ) чаще, чем длинные (например, упорядочить 
файл с миллионами записей), то компьютер может обеспечивать быстрое интерак¬ 
тивное обслуживание нескольких пользователей. При этом он может работать над 
большими пакетами в фоновом режиме, когда центральный процессор не занят 
другими заданиями. Первая серьезная система с режимом разделения времени 
СТ55 (СотраііЫе Тіше 5Ьагіп§ Зузіеш — Совместимая система разделения вре¬ 
мени) была разработана в Массачусетсском технологическом институте (М.І.Т.) 
на специально переделанном компьютере ІВМ 7094 [75]. Однако режим разделе¬ 
ния времени не стал действительно популярным до тех пор, пока не получили 
широкого распространения необходимые технические средства защиты. 

После успеха системы СТ55 Массачусетсский технологический институт, сис¬ 
тема исследовательских лабораторий Веіі ЬаЬз и корпорация Сепегаі Еіесігіс (тогда 
главный изготовитель компьютеров) решили начать разработку «компьютерного 
предприятия общественного пользования» — машины, которая должна была под¬ 
держивать сотни одновременных пользователей в режиме разделения времени. 
Образцом для новой машины послужила система распределения электроэнергии. 
Когда вам нужна электроэнергия, вы просто вставляете штепсель в розетку и по¬ 
лучаете энергии столько, сколько вам нужно. Проектировщики этой системы, из¬ 
вестной как М1ЛЛ1С5 (МЕІЕТірІехесІ Іпіогтаііоп апсі Сотрц1іп§ Зегѵісе — муль¬ 
типлексная информационная и вычислительная служба), представляли себе одну 
огромную вычислительную машину, воспользоваться услугой которой мог каждый 


' В этой книге мы будем использовать термины «процедура», «подпрограмма» и «функция» в одном 
значении. — Примеч. авт. 
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человек в районе Бостона. Мысль о том, что машины, гораздо более мощные, чем 
их мэйнфрейм СЕ-645, будут продаваться миллионами по цене тысяча долларов 
за штуку всего лишь через тридцать лет, казалась чистейшей научной фантасти¬ 
кой, как если бы сегодня кто-либо вздумал проектировать сверхзвуковые трансат¬ 
лантические подводные поезда. 

Успех системы МЩ.ТІС5 был весьма неоднозначен. Эта система разрабаты¬ 
валась для того, чтобы обеспечить сотни пользователей машиной, немногим более 
мощной, чем персональный компьютер с процессором Іпіеі 386, хотя при этом 
имеющей возможность работы со значительно большим количеством устройств 
ввода-вывода. Это было не так уж безумно, как может показаться, потому что в те 
дни люди знали, как писать маленькие, эффективные программы — навык, кото¬ 
рый впоследствии был утерян. Существовало много причин, по которым система 
МЩ.ТІС5 не захватила весь мир. Не последнюю роль сыграл тот факт, что эта 
система была написана на языке РБ/І, а компилятор языка РБ/І появился лишь 
через несколько лет, к тому же первую версию этого компилятора можно было 
назвать работоспособной с большой натяжкой. Кроме того, система ІѴШЕТІС5 
была чрезвычайно претенциозна для своего времени, во многом походя на анали¬ 
тическую машину Чарльза Бэббиджа в девятнадцатом столетии. 

Итак, МІІБТІС5 подала много конструктивных идей компьютерным теорети¬ 
кам, но превратить ее в серьезный продукт и добиться коммерческого успеха ока¬ 
залось намного тяжелее, чем ожидалось. Система исследовательских лабораторий 
Веіі БаЬз выбыла из проекта, а компания Сепегаі Еіесігіс совсем оставила компью¬ 
терный бизнес. Однако Массачусетсский технологический институт проявил упор¬ 
ство и со временем получил работающую систему. В конце концов, она была про¬ 
дана как коммерческое изделие компанией Нопеу\ѵе11, купившей компьютерный 
бизнес Сепегаі ЕІесСгіс, и установлена примерно в восьмидесяти больших компани¬ 
ях и университетах по всему миру. Несмотря на свою малочисленность, пользова¬ 
тели системы МЩ.ТІС5 были отчаянно преданы ей. Например, компании Сепегаі 
Моіогз, Рогсі и Управление национальной безопасности США оставили свои сис¬ 
темы МІЛ.ТІС5 только в конце 90-х годов, через 30 лет после выхода системы. 

К настоящему времени идея компьютерного предприятия общественного 
пользования выдохлась, но она может благополучно вернуться к жизни в форме 
массивных централизованных Интернет-серверов, выполняющих основную часть 
работы, к которым будут присоединены относительно «глупые» пользовательские 
машины. Мотивировка, вероятно, будет следующей: большинство пользователей 
не захочет администрировать все более усложняющуюся и привередливую систему 
компьютера и предпочтет доверить эту работу команде профессионалов, работаю¬ 
щих на обслуживающую сервер компанию. Электронная коммерция уже развива¬ 
ется в этом направлении, создаются различные компании, управляющие электрон¬ 
ными супермаркетами на многопроцессорных серверах, с которыми соединяются 
простые машины клиентов. Все это очень напоминает замысел системы МБІБТІС5. 

Несмотря на неудачу с точки зрения коммерции, система МБІБТІС5 значитель¬ 
но повлияла на последующие операционные системы. Это описано в книгах [76, 
77, 82, 253, 285]. Системе ІѴШБТІС5 также посвящен все еще активный \ѵеЬ-сайт 
ѵѵѵѵѵѵ.тиФісіапз.огд, с большим количеством информации о системе, ее проектиров¬ 
щиках и пользователях. 
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Еще одним важным моментом развития во времена третьего поколения был 
феноменальный рост мини-компьютеров, начиная с выпуска машины РЭР-1 кор¬ 
порацией БЕС в 1961 году. Компьютеры РЭР-1 обладали оперативной памятью, 
состоящей всего лишь из 4 К 18-битовых слов, но стоили они по 120 тысяч долла¬ 
ров за штуку (это меньше 5 % от цены ІВМ 7094) и поэтому расхватывались как 
горячие пирожки. На некоторых видах нечисловой работы они работали почти 
с такой же скоростью, как ІВМ 7094, что дало толчок к появлению новой индуст¬ 
рии. За этой машиной последовала целая серия других РЭР (в отличие от семей¬ 
ства ІВМ, полностью несовместимых), и как кульминация — РЭР-11. 

Кен Томпсон (Кеп ТЬотрзоп), один из специалистов по компьютерам в Веіі 
ЬаЬз, работавший над проектом МШЛ1С5, впоследствии нашел мини-компьютер 
РЭР-7, которым никто не пользовался, и решил написать усеченную однопользо¬ 
вательскую версию системы МІЛЛІСЗ. Эта работа позже развилась в операцион¬ 
ную систему ІШІХ®, ставшую популярной в академическом мире, в правитель¬ 
ственных управлениях и во многих компаниях. 

История развития ИШХ уже многократно рассказывалась в самых различных 
книгах (например [288]). Часть ее будет представлена в главе 10. Пока достаточно 
сказать, что по причине широкой доступности исходного кода различные организа¬ 
ции создали свои собственные (несовместимые) версии, что привело к хаосу. Были 
разработаны две главные версии: Зузіет V корпорации АТ&Т и В5Б (Вегкеіеу 
ЗоЙхѵаге ОізІгіЬиІіоп) Калифорнийского университета Беркли. Эти системы, в свою 
очередь, распадаются на отдельные разновидности. Чтобы стало возможным писать 
программы, работающие в любой ІШІХ-системе, Институт инженеров по электро¬ 
технике и электронике ІЕЕЕ разработал стандарт системы ИШХ, называемый 
Р05ІХ, который теперь поддерживают большинство версий ІШІХ. Стандарт РОЗІХ 
определяет минимальный интерфейс системного вызова, который должны поддер¬ 
живать совместимые системы ИШХ. Некоторые другие операционные системы 
теперь тоже поддерживают интерфейс РОЗІХ. 

Отдельно стоит упомянуть, что в 1987 году автор создал маленький клон сис¬ 
темы ИШХ для образовательных целей, так называемую систему МШІХ. Функ¬ 
ционально система МШІХ очень похожа на ИШХ, включая поддержку стандарта 
РОЗІХ. Существует книга, описывающая внутренние операции МШІХ, к которой 
прилагается листинг исходного кода [326]. Система МШІХ свободно распростра¬ 
няется (включая весь исходный код) через Интернет по адресу: ѵѵѵѵѵѵ.С5.ѵи.пІ/~а5І/ 
тіпіх.ЬітІ. 

Желание иметь свободно распространяемую рабочую (в противоположность 
образовательной) версию МШІХ подвигло финского студента Линуса Торвальд¬ 
са (Біпиз ТогѵаЫз) к написанию системы Еіпих. Эта система была разработана на 
основе МШІХ и первоначально обладала ее характерными особенностями (напри¬ 
мер, поддерживала ту же файловую систему). С тех пор система Біппх была зна¬ 
чительно расширена, но она все еще сохраняет большую часть структуры, общей 
как для системы МШІХ, так и для системы ИШХ (на которой и была основана 
система МШІХ). Большая часть того, что будет сказано о ИШХ в этой книге, при¬ 
менимо к Зузіеш V, ВЗИ, МШІХ, Біпих, а также к другим версиям и клонам ІШІХ. 
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Четвертое поколение (с 1980 года по наши дни): 
персональные компьютеры 

Следующий период в эволюции операционных систем связан с появлением Боль¬ 
ших Интегральных Схем (Б5І, Баг§е 5са1е ІпІе§гаІіоп) — кремниевых микросхем, 
содержащих тысячи транзисторов на одном квадратном сантиметре. С точки зре¬ 
ния архитектуры персональные компьютеры (первоначально называемые микро¬ 
компьютерами) были во многом похожи на мини-компьютеры класса РИР-1 1, но, 
конечно, отличались по цене. Если появление мини-компьютеров позволило от¬ 
делам компаний и факультетам университетов иметь собственный компьютер, 
то с появлением микропроцессоров каждый человек получил возможность купить 
свой собственный персональный компьютер. 

В 1974 году, когда компания ІпіеІ выпустила ІпіеІ 8080 — первый универсаль¬ 
ный 8-разрядный центральный процессор, — для него потребовалась операцион¬ 
ная система, с помощью которой можно было бы протестировать новинку. Компа¬ 
ния ІпіеІ привлекла к разработкам и написанию нужной операционной системы 
одного из своих консультантов Гзри Килдэлла (Сагу Кіісіаіі). Сначала Килдэлл 
с другом сконструировали контроллер для 8-дюймового гибкого диска, недавно 
выпущенного компанией 5Ьи§агІ Аззосіаіез, и подключили этот диск к процессо¬ 
ру ІпіеІ 8080. Таким образом, появился первый микрокомпьютер с диском. Затем 
Килдэлл создал дисковую операционную систему, названную СР/М (Сопігоі 
Рго§гат Іог Місгосотриіегз — программа управления для микрокомпьютеров). 
Когда Килдэлл заявил о своих правах на СР/М, корпорация ІпіеІ удовлетворила 
его просьбу, поскольку не думала, что у микрокомпьютеров с диском есть буду¬ 
щее. Позже Килдэлл создал свою компанию Оі§іІа1 КезеагсЬ для дальнейшего раз¬ 
вития и продажи СР/М. 

В 1977 году компания Оі§іІа1 КезеагсЬ переработала СР/М, чтобы сделать эту 
систему пригодной для работы на микрокомпьютерах с процессорами ІпіеІ 8080 
или 2і1о§ 280, а также с другими процессорами. Затем было написано множество 
прикладных программ, работающих в СР/М, что позволило СР/М занимать выс¬ 
шую позицию в мире микрокомпьютеров на протяжении 5 лет. 

В начале 80-х корпорация ІВМ разработала ІВМ РС (Регзопаі Сошриіег — 
персональный компьютер) и начала искать для него программное обеспечение. 
Сотрудники ІВМ связались с Биллом Гейтсом (Вііі СаІез), чтобы получить ли¬ 
цензию на право использования его интерпретатора языка Бейсик (ВА5ІС). Они 
также поинтересовались, не знает ли он операционную систему, которая работала 
бы на РС. Гейтс посоветовал обратиться к Оі§іІа1 КезеагсЬ, тогда главенствующей 
компании по операционным системам. Но Килдэлл отказался встречаться с ІВМ, 
послав вместо себя подчиненного. Что еще хуже, его адвокат даже отказался под¬ 
писывать соглашение о неразглашении, касающееся еще не выпущенного РС, чем 
полностью испортил дело. Корпорация ІВМ снова обратилась к Гейтсу с просьбой 
обеспечить ее операционной системой. 

После повторного запроса ІВМ Гейтс выяснил, что у местного изготовителя 
компьютеров, Зеаіііе Сошриіег Ргосіисіз, есть подходящая операционная система 
005 (Оізк ОрегаІіп§ Зузіет — дисковая операционная система). Он направился 
в эту компанию с предложением выкупить БОЗ (предположительно за $50 000), 
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которое компания ЗеаШе Сошриіег РгобисС с готовностью приняла. Затем Гейтс 
создал пакет программ Б05/ВА5ІС, и пакет был куплен ІВМ. Когда корпорация 
ІВМ захотела некоторых усовершенствований в программе, Билл Гейтс пригла¬ 
сил для этой работы Тима Патерсона (Тіпг Раіегзоп), человека, написавшего Б05, 
ставшего первым служащим еще не оперившейся компании Гейтса МісгозоЙ. Ви¬ 
доизмененная система была переименована в М5-005 (МісгоЗоЙ Бізк Орега!іп§ 
Зузіет) и быстро заняла доминирующее положение на рынке ІВМ РС. Самым 
важным оказалось решение Гейтса (как оказалось, чрезвычайно мудрое) продать 
М5-005 компьютерным компаниям для установки вместе с их оборудованием, 
в отличие от попыток Килдэлла продавать СР/М конечным пользователям (по 
крайней мере, на начальной стадии). 

Когда в 1983 году появился компьютер ІВМ РС/АТ с центральным процессо¬ 
ром Іпіеі 80286, система М5-Б05 уже прочно стояла на ногах, а СР/М доживала 
свои последние дни. Позже система МЗ-005 широко использовалась на компью¬ 
терах с процессорами 80386 и 80486. Хотя первоначальная версия МЗ-ООЗ была 
довольно примитивна, последующие версии системы выходили со все лучше раз¬ 
работанными свойствами, включая многое, позаимствованное от ІЖІХ. (Корпо¬ 
рация МісгозоД была неплохо информирована о системе ІШІХ и даже продавала 
ее микрокомпьютерную версию ХЕЕІІХ в первые годы своего существования.) 

СР/М, М5-Б05 и другие операционные системы для первых микрокомпьюте¬ 
ров полностью основывались на вводе команд с клавиатуры. Затем, благодаря 
исследованиям, проведенным в 60-е годы Дагом Энгельбартом (Оои§ Еп§е1Ьаг1) 
в научно-исследовательском институте Стэнфорда (ЗіапГогсі КезеагсЬ ІпзІіІиІе), 
это свойство операционных систем изменилось. Энгельбарт изобрел графический 
интерфейс пользователя (СШ, СгарЬісаІ Шег Іпіегіасе, произносимый как 
«гуи» 1 ), состоящий из окон, значков, различных меню и мыши. Эту идею переня¬ 
ли разработчики из Хегох РАКС и встроили в сконструированные ими машины. 

Однажды Стив Джобс (Зіеѵе іоЬз), тот самый, который изобрел компьютер 
Арріе в своем собственном гараже, посетил РАКС, где увидел СШ и тотчас осоз¬ 
нал его потенциальную ценность, практически не осознаваемую руководством 
Хегох [307]. Тогда Джобс приступил к созданию Арріе с графическим интерфей¬ 
сом. Это привело к проекту Біза, который был слишком дорог и потерпел коммер¬ 
ческую неудачу. Вторая попытка Джобса, Арріе МасіпІозЬ, имела огромный успех 
не только из-за дешевизны, но и потому, что на нем работал дружественный ин¬ 
терфейс, то есть предназначенный для пользователей, ничего не знающих о компь¬ 
ютерах и, более того, вовсе не желающих чему-либо обучаться. 

Когда корпорация МісгозоД решила создать преемника М5-Э05, она находи¬ 
лась полностью под влиянием успехов компании МасіпІозЬ. Была разработана 
система, получившая название \ѴіпсІо\ѵ5, базой для которой послужил СШ. Сис¬ 
тема \ѴіпсІо\ѵ5 первоначально работала поверх М5-Э05 (то есть это была скорее 
оболочка, чем настоящая операционная система). На протяжении 10 лет, с 1985 
по 1995 год, система \ѴіпсІо\ѵ5 исполняла роль графической среды поверх МЗ-ООЗ. 
Однако в 1995 году вышла в свет автономная версия \ѴіпсІо\ѵ5 95. Она включила 
в себя множество особенностей операционной системы М5-005, но только для 


1 В переводе означает «липкий». — Примеч. перев. 
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загрузки и выполнения старых программ. В 1998 году была выпущена слегка из¬ 
мененная версия этой системы, получившая название ГѴіпсіоѵуз 98. Тем не менее и 
\ѴіпсІо\ѵз 95, и \ѴіпсІо\ѵз 98 все еще содержат большое количество программ 16- 
разрядного ассемблера Іпіеі. 

Другой операционной системой Місгозой стала \Ѵіпс1о\ѵз ІѴТ (N4 означает №\ѵ 
ТесЬпо1о§у — новая технология), которая на определенном уровне совместима 
с \ѴіпсІо\ѵз 95, но ее ядро написано полностью заново. Это целиком 32-разрядная 
система. Дэвид Катлер (ЭаѵісІ Сиііег), главный разработчик \ѴіпсІо\У5 КТ, был 
также одним из создателей операционной системы ѴМ5 для компьютеров ѴАХ, 
поэтому некоторые идеи системы ѴМ5 присутствуют и в КТ. Корпорация Місго- 
зой ожидала, что первая же версия КТ вытеснит М5-Э05 и все другие версии 
\ѴіпсІо\ѵз, так как это была система, намного превосходящая предыдущие, но надеж¬ 
да не оправдалась. И только системе \ѴіпсІо\ѵз КТ 4.0 наконец-то удалось получить 
относительно широкое распространение, особенно в корпоративных сетях. Версия 
\ѴтсІо\ѵ5 КТ 5.0 была переименована в \ѴіпсІо\Ѵ5 2000 в начале 1999 года. Она должна 
была стать преемником и \ѴіпсІо\ѵз 98, и \ѴіпсІо\ѵз КТ 4.0. Но этому также не было 
суждено случиться, поэтому корпорация МісгозоЙ выпустила еще одну версию 
\Ѵіпс1о\ѵз 98, названную \Ѵіпсіо\ѵз Ме (Міііеппіит есіійоп — выпуск тысячелетия). 

Главным соперником \ѴіпсІо\ѵ5 в мире персональных компьютеров становится 
система ГПЧІХ (и ее различные производные). ИКІХ является самой сильной 
системой для рабочих станций и других компьютеров старших моделей, таких как 
сетевые серверы. Она стала особенно популярна на машинах с высокопроизводи¬ 
тельными КІ5С-процессорами (К.І5С, гесіисесі іпзігисііоп зеі сотриіег — компью¬ 
тер с сокращенным набором команд). На компьютерах с процессорами Репііиш 
популярной альтернативой \Ѵіпсіо\ѵз для студентов и других разнообразных 
пользователей становится Ьіпих (в дальнейшем мы будем использовать термин 
«Репііиш», подразумевая Репііит I, II, III и 4). 

Хотя многие пользователи ШѴІХ, особенно опытные программисты, предпо¬ 
читают командный интерфейс графическому, почти все ГІКІХ-системы поддержи¬ 
вают оконную систему, созданную в Массачусетсском технологическом институте. 
Она называется X ХѴішІоѵѵз. Эта система оперирует основными функциями окна, 
позволяя пользователю создавать, удалять, перемещать окна и изменять их разме¬ 
ры с помощью мыши. Часто поверх системы X \ѴіпсІо\ѵз может быть установлен 
полный графический интерфейс, например МоііГ, придающий системе ГІКІХ вне¬ 
шний вид системы типа МісгозоЙ \ѴтсІо\У5 или как у компьютера МасіпІозЬ. 

С середины 80-х годов начали расти и развиваться сети персональных компью¬ 
теров, управляемых сетевыми и распределенными операционными системами 
[325]. В сетевой операционной системе пользователи знают о существовании 
многочисленных компьютеров, могут регистрироваться на удаленных машинах 
и копировать файлы с одной машины на другую. Каждый компьютер работает под 
управлением локальной операционной системы и имеет своего собственного локаль¬ 
ного пользователя (или пользователей). 

Сетевые операционные системы несущественно отличаются от однопроцессор¬ 
ных операционных систем. Ясно, что они нуждаются в сетевом интерфейсном кон¬ 
троллере и специальном низкоуровневом программном обеспечении, поддержи¬ 
вающем работу контроллера, а также в программах, разрешающих пользователям 
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удаленную регистрацию в системе и доступ к удаленным файлам. Но эти допол¬ 
нения, по сути, не изменяют структуры операционной системы. 

Распределенная операционная система, напротив, представляется пользовате¬ 
лям традиционной однопроцессорной системой, хотя она и составлена из множе¬ 
ства процессоров. При этом пользователи не должны беспокоиться о том, где ра¬ 
ботают их программы или где расположены файлы; все это должно автоматически 
и эффективно обрабатываться самой операционной системой. 

Чтобы создать настоящую распределенную операционную систему, недостаточ¬ 
но просто добавить несколько страниц кода к однопроцессорной операционной 
системе, так как распределенные и централизованные системы имеют существен¬ 
ные различия. Распределенные системы, например, часто позволяют прикладным 
задачам одновременно обрабатываться на нескольких процессорах, поэтому тре¬ 
буется более сложный алгоритм загрузки процессоров для оптимизации распарал¬ 
леливания. 

Наличие задержек при передаче данных в сетях означает, что эти алгоритмы 
должны работать с неполной, устаревшей или даже неправильной информацией. 
Эта ситуация радикально отличается от однопроцессорной системы, в которой 
операционная система обладает полной информацией относительно состояния 
системы. 

Онтогенез повторяет филогенез 

После опубликования книги Чарльза Дарвина «Происхождение видов» немецкий 
зоолог Эрнст Хэккель (Егпзі; Наескеі) сформулировал правило: «Онтогенез повто¬ 
ряет филогенез». Сказав это, он имел в виду, что развитие зародыша (онтогенез) 
повторяет эволюцию видов (филогенез). Другими словами, человеческая яй¬ 
цеклетка от момента оплодотворения до того, как стать человеческим ребенком, 
проходит через состояния рыбы, свиньи и т. д. Современные биологи считают 
такую модель очень сильно и грубо упрощенной, но все же в ней присутствует 
зерно истины. 

Нечто подобное произошло в компьютерной промышленности. Каждый новый 
вид (мэйнфрейм, мини-компьютер, персональный компьютер, встроенный компь¬ 
ютер, смарт-карта и т. д.) проходит, видимо, через те же стадии развития, что и их 
предки. Первые мэйнфреймы программировались полностью на языке ассемб¬ 
лера. Даже такие сложные программы, как компиляторы и операционные систе¬ 
мы, в те времена писали на ассемблере. Когда появились мини-компьютеры, на 
мэйнфреймах уже стали обычными Фортран, Кобол и другие языки программи¬ 
рования высокого уровня, но тем не менее на новых мини-компьютерах програм¬ 
мировали на ассемблере (из-за недостатка памяти). Когда были созданы микро¬ 
компьютеры (самые первые персональные компьютеры), программирование на 
них также велось на ассемблере, несмотря на то, что к этому времени на мини¬ 
компьютерах уже применялось программирование на языках высокого уровня. 
Карманные компьютеры тоже начинались с ассемблерных программ, но очень 
быстро перешли на языки высокого уровня (в основном за счет того, что к тому 
моменту они уже разрабатывались на больших машинах). То же самое относится 
и к смарт-картам. 
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А теперь взглянем на операционные системы. Первые мэйнфреймы изначаль¬ 
но не имели защитного оборудования и поддержки многозадачности, поэтому на 
них работали простые операционные системы, управляющие в каждый конкрет¬ 
ный момент времени только одной загруженной вручную программой. Позже на 
этих машинах появилось необходимое оборудование и операционные системы, 
поддерживающие управление одновременно несколькими программами, а затем 
и полная возможность работы в режиме разделения времени. 

Когда мини-компьютеры только появились на свет, на них также не было за¬ 
щитной аппаратуры и в каждый конкретный момент времени могла работать толь¬ 
ко одна загруженная вручную программа, несмотря на то, что к тому времени 
многозадачность уже была разработана и хорошо работала в мире мэйнфреймов. 
Постепенно мини-компьютеры обзавелись защитным оборудованием и появилась 
возможность одновременной работы на них двух или более программ. На первых 
микрокомпьютерах также в каждый момент времени могла работать только одна 
программа, и только позже стал возможным многозадачный режим. Тем же путем 
развивались карманные компьютеры и смарт-карты. 

Диски впервые появились на больших мэйнфреймах и только затем на мини¬ 
компьютерах, микрокомпьютерах и т. д. Даже сейчас на смарт-картах нет жестко¬ 
го диска, но с появлением флэш-памяти вскоре будут созданы эквиваленты дис¬ 
ков и для карт. Лишь после возникновения первых дисков возникли примитивные 
файловые системы. На компьютере СБС 6600, который смело можно назвать са¬ 
мым мощным мэйнфреймом 60-х годов, пользователи файловой системы имели 
возможность создавать файл и затем объявлять этот файл постоянным. Это озна¬ 
чало, что он останется на диске даже после завершения работы создавшей его 
программы. Для получения доступа к этому файлу программа должна была под¬ 
ключить его с помощью специальной команды, указав пароль (который задавался 
в тот момент, когда файл объявлялся постоянным). В сущности, тогда на компью¬ 
тере был всего один каталог, совместно используемый всеми пользователями. Кон¬ 
фликты имен файлов должны были разрешаться самими пользователями. Так же 
все начиналось и на мини-компьютерах: ранние файловые системы имели один ката¬ 
лог, общий для всех пользователей; это верно и для ранних микрокомпьютерных 
файловых систем. 

Виртуальная память (то есть виртуальное устройство, позволяющее работать 
программам, требующим больше памяти, чем физически имеется у компьютера) 
развивалась точно таким же образом. Сначала она появилась на мэйнфреймах, затем 
на мини-компьютерах, микрокомпьютерах и постепенно заработала на все мень¬ 
ших и меньших системах. Сети имеют очень похожую историю. 

Во всех случаях развитие программного обеспечения диктовалось ростом техно¬ 
логий. Например, на первых микрокомпьютерах было что-то около 4 Кбайт памяти 
и отсутствовала аппаратная защита. Соответственно, для управления такой крошеч¬ 
ной системой не годились языки высокого уровня и многозадачность, они были 
просто слишком громоздки. По мере того как микрокомпьютеры эволюционировали 
в современные персональные компьютеры, на них появилось необходимое обору¬ 
дование, а потом и программное обеспечение для управления этими более сложны¬ 
ми устройствами. Вероятно, подобное развитие продолжится в течение последующих 
лет. В других областях также действует это правило перевоплощения, но в компью¬ 
терной промышленности, как нам кажется, развитие происходит заметно быстрее. 
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Зоопарк операционных систем 

Описанное выше развитие компьютеров привело к появлению огромного количе¬ 
ства различных операционных систем, далеко не все из которых широко извест¬ 
ны. В этом разделе мы кратко рассмотрим семь из них. К некоторым системам из 
перечисленных ниже мы вернемся позже в нашей книге. 

Операционные системы мэйнфреймов 

На самом верхнем уровне находятся операционные системы для мэйнфреймов. 
Эти компьютеры размером с комнату все еще можно встретить в центрах данных 
больших корпораций. Мэйнфреймы отличаются от персональных компьютеров по 
своим возможностям ввода-вывода. Довольно часто встречаются мэйнфреймы 
с тысячью дисков и терабайтами данных, а персональный компьютер с такими 
параметрами показался бы действительно необычным. Мэйнфреймы как бы воз¬ 
вращаются в виде мощных \ѵеЬ-серверов, серверов для крупномасштабных элект¬ 
ронно-коммерческих сайтов и серверов для транзакций в бизнесе. 

Операционные системы для мэйнфреймов в основном ориентированы на об¬ 
работку множества одновременных заданий, большинству из которых требуется 
огромное количество операций ввода-вывода. Обычно они предлагают три вида 
обслуживания: пакетную обработку, обработку транзакций (групповые операции) 
и разделение времени. Пакетная обработка представляет собой систему, выпол¬ 
няющую стандартные задания без присутствия пользователей, работающих в ин¬ 
терактивном режиме. Обработка исков в страховых компаниях или составление 
отчетов о продажах для цепи магазинов — это типичные задания, обрабатываемые 
в пакетном режиме. Системы обработки транзакций управляют очень большим 
количеством маленьких запросов, например контролируют процесс работы в банке 
или бронирование авиабилетов. Каждый отдельный запрос невелик, но система 
должна отвечать на сотни или тысячи запросов в секунду. Системы, работающие 
в режиме разделения времени, позволяют множеству удаленных пользователей од¬ 
новременно выполнять свои задания на одной машине. Хорошим примером являет¬ 
ся работа с большой базой данных. Все эти функции тесно связаны между собой, 
и зачастую операционная система мэйнфрейма выполняет их все. Примером опе¬ 
рационной системы для мэйнфрейма является 05/390, произошедшая от 05/360. 

Серверные операционные системы 

Уровнем ниже находятся серверные операционные системы. Они работают на 
серверах, которые представляют собой или очень большие персональные компью¬ 
теры, или рабочие станции, или даже мэйнфреймы. Они одновременно обслужи¬ 
вают множество пользователей и позволяют им делить между собой программные 
и аппаратные ресурсы. Серверы предоставляют возможность работы с печата¬ 
ющими устройствами, файлами или Интернетом. Интернет-провайдеры обычно 
запускают в работу несколько серверов для того, чтобы поддерживать одновре¬ 
менный доступ к сети множества клиентов. На серверах хранятся страницы \ѵеЬ- 
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сайтов и обрабатываются входящие запросы. ЬПЧІХ и \Ѵпк1о\ѵ$ 2000 являются 
типичными серверными операционными системами. Теперь в этих целях стала ис¬ 
пользоваться и операционная система Ьіпих. 

Многопроцессорные операционные системы 

Все более часто применяемый способ увеличения мощности компьютеров заклю¬ 
чается в соединении нескольких центральных процессоров в одной системе. В за¬ 
висимости от вида соединения процессоров и разделения работы такие системы 
называются параллельными компьютерами, мультикомпьютерами или многопро¬ 
цессорными системами. Для них требуются специальные операционные системы, 
но зачастую такие операционные системы представляют собой варианты сервер¬ 
ных операционных систем со специальными возможностями связи. 

Операционные системы для персональных 
компьютеров 

Следующую категорию составляют операционные системы для персональных 
компьютеров. Их работа заключается в предоставлении удобного интерфейса для 
одного пользователя. Такие системы широко используются для работы с текстом, 
электронными таблицами и доступа к Интернету. Наиболее яркие примеры — это 
АУіпсІоѵѵз 98, \Ѵіпс1о\Ѵ5 2000, операционная система компьютера МасіпСозЬ и Ьіпих. 
Операционные системы для персональных компьютеров настолько хорошо изве¬ 
стны, что вряд ли необходимо представлять здесь их краткий обзор. На самом деле 
множество людей даже не имеет понятия о существовании других видов операци¬ 
онных систем, кроме той, которой они пользуются. 

Операционные системы реального времени 

Еще один вид операционной системы — это системы реального времени. Главным 
параметром таких систем является время. Например, в системах управления про¬ 
изводством компьютеры, работающие в режиме реального времени, собирают дан¬ 
ные о промышленном процессе и используют их для управления машинами на 
фабрике. Часто такие процессы должны удовлетворять жестким временным тре¬ 
бованиям. Так, если автомобиль передвигается по конвейеру, то каждое действие 
должно быть осуществлено в строго определенный момент времени. Если свароч¬ 
ный робот сварит шов слишком рано или слишком поздно, то нанесет непопра¬ 
вимый вред машине. Если некоторое действие должно произойти в конкретный 
момент времени (или внутри заданного диапазона времени), мы имеем дело с жест¬ 
кой системой реального времени. 

Существует и другой вид: гибкая система реального времени, в которой допу¬ 
стимы случающиеся время от времени пропуски сроков выполнения операции. 
В эту категорию попадают цифровое аудио и мультимедийные системы. Системы 
ѴхѴ/огкя и (ЖХ являются хорошо известными операционными системами реаль¬ 
ного времени. 
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Встроенные операционные системы 

Продолжая двигаться от огромных систем ко все меньшим, мы добрались до «кар¬ 
манных» компьютеров и встроенных систем. Карманный компьютер или РОА 
(Регзопаі Віфіаі Аззізіапі — персональный цифровой помощник) — это малень¬ 
кий компьютер, помещающийся в кармане брюк, выполняющий небольшой набор 
функций (телефонной записной книжки и блокнота). Встроенные системы, управ¬ 
ляющие действиями устройств, работают на машинах, обычно не считающихся 
компьютерами, например в телевизорах, микроволновых печах и мобильных те¬ 
лефонах. Они часто обладают теми же самыми характеристиками, что и системы 
реального времени, но при этом имеют особый размер, память и ограничения мощ¬ 
ности, что выделяет их в отдельный класс. Примерами таких операционных сис¬ 
тем являются РаІшОЗ и \Ѵіпс1о\ѵ5 СЕ (Сопзишег Еіесігопісз — бытовая техника). 


Операционные системы для смарт-карт 

Самые маленькие операционные системы работают на смарт-картах, представля¬ 
ющих собой устройство размером с кредитную карту, содержащее центральный 
процессор. На такие операционные системы накладываются крайне жесткие огра¬ 
ничения по мощности процессора и памяти. Некоторые из них могут управлять 
только одной операцией, например электронным платежом, но другие операцион¬ 
ные системы на тех же самых смарт-картах выполняют сложные функции. Зачас¬ 
тую они являются патентованными системами. 

Некоторые смарт-карты являются ^ѵа-ориентированными. Это означает, что 
ПЗУ (постоянная память, по-английски она называется КОМ, Кеаб Опіу Мешогу — 
память только для чтения) смарт-карт содержит интерпретатор виртуальной ма¬ 
шины ^ѵа ОѴМ,^ѵа Ѵігіиаі МасЬіпе). Апплеты^ѵа (маленькие программы) за¬ 
гружаются на карту и выполняются ^ІѴМ-интерпретатором. Некоторые из таких 
карт могут одновременно управлять несколькими апплетами ^ѵа, что приводит 
к многозадачности и необходимости планирования. Из-за одновременной работы 
двух и более программ возникает необходимость в управлении ресурсами и защи¬ 
той. Соответственно, все эти задачи выполняет обычно крайне примитивная опе¬ 
рационная система, находящаяся на смарт-карте. 


Обзор аппаратного обеспечения 
компьютера 

Операционная система тесно связана с оборудованием компьютера, на котором она 
должна работать. Аппаратное обеспечение влияет на набор команд операционной 
системы и управление его ресурсами. Поэтому нам необходим определенный 
объем знаний о компьютере, по крайней мере нужно представлять, в каком виде 
оборудование предстает перед программистом. 

Концептуально простой персональный компьютер можно представить в виде 
абстрактной модели, аналогичной той, которая показана на рис. 1.5. Центральный 
процессор, память и устройства ввода-вывода соединены системной шиной, по 
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которой они обмениваются друг с другом информацией. Современные персональ¬ 
ные компьютеры имеют более сложную структуру, включающую несколько шин; 
мы вспомним об этом позже. Для начала модели, представленной на рисунке, вполне 
достаточно. В следующих разделах мы кратко рассмотрим отдельные компоненты 
и исследуем некоторые аппаратные аспекты, имеющие отношение к разработке 
операционной системы. 



Виз 


Рис. 1 .5. Некоторые компоненты персонального компьютера 


Процессоры 

«Мозгом» компьютера является центральный процессор (СРІІ — Сел Іга] Ргосе55Іл§ 
Ипк). Он выбирает из памяти команды и выполняет их. Обычный цикл работы 
центрального процессора выглядит так: он читает первую команду из памяти, деко¬ 
дирует ее для определения ее типа и операндов, выполняет команду, затем считы¬ 
вает, декодирует и выполняет последующие команды. Таким образом осуществ¬ 
ляется выполнение программ. 

Для каждого центрального процессора существует набор команд, который он 
в состоянии выполнить. Например, процессор РепНит не может обработать 
программы, написанные для 5РАК.С, а процессор 5РАК.С не может выполнить 
программы, написанные для РепНит. Поскольку доступ к памяти для получения 
команд или наборов данных занимает намного больше времени, чем выполнение 
этих команд, все центральные процессоры содержат внутренние регистры для хра¬ 
нения ключевых переменных и временных результатов. Поэтому набор инструк¬ 
ций обычно содержит команды для загрузки слова из памяти в регистр и сохра¬ 
нения слова из регистра в памяти. Другие команды объединяют два операнда из 
регистров, памяти или и того и другого и получают результат. Например, склады¬ 
вают два слова и сохраняют результат в регистре или памяти. 

Кроме основных регистров, используемых для хранения переменных и времен¬ 
ных результатов, большинство компьютеров имеет несколько специальных регис¬ 
тров, видимых для программиста. Один из них называется счетчиком команд (РС, 
рго§гат соиліег), в нем содержится адрес следующей, стоящей в очереди на вы- 
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полнение команды. После того как команда выбрана из памяти, регистр команд 
корректируется и указатель переходит к следующей команде. 

Еще один регистр процессора называется указателем стека (5Р, зіаск роіпіег). 
Он содержит адрес вершины стека в памяти. Стек содержит по одному фрейму 
(области данных) для каждой процедуры, которая уже начала выполняться, но еще 
не закончена. В стековом фрейме процедуры хранятся ее входные параметры, а так¬ 
же локальные и временные переменные, не хранящиеся в регистрах. 

Следующий регистр называется Р8\Ѵ (Ргосеззог Зіаіия \Уогй — слово состоя¬ 
ния процессора). Этот регистр содержит биты кода состояний, которые задаются 
командами сравнения, приоритетом центрального процессора, режимом (пользова¬ 
тельский или режим ядра), и другую служебную информацию. Обычно пользова¬ 
тельские программы могут читать весь регистр Р5\Ѵ целиком, но писать могут 
только в некоторые из его полей. Регистр Р8\Ѵ играет важную роль в системных 
вызовах и операциях ввода-вывода. 

Операционная система должна знать все обо всех регистрах. При временном 
мультиплексировании центрального процессора операционная система часто ос¬ 
танавливает работающую программу для запуска (или перезапуска) другой. Каж¬ 
дый раз при таком прерывании операционная система должна сохранять все реги¬ 
стры процессора, чтобы позже, когда программа продолжит свою работу, их можно 
было восстановить. 

В целях улучшения характеристик центральных процессоров их разработчики 
давно отказались от простой модели, в которой за один такт может быть считана, 
декодирована и выполнена только одна команда. Многие современные СРИ обла¬ 
дают возможностями выполнения нескольких команд одновременно. Например, 
у процессора могут быть раздельные модули, занимающиеся выборкой, декодиро¬ 
ванием и выполнением команд, и во время выполнения команды с номером п он 
может декодировать команду с номером п + 1 и считывать команду с номером п + 2. 
Подобная организация процесса называется конвейером, три его стадии продемон¬ 
стрированы на рис. 1.6, а. Часто встречаются и более длинные конвейеры. В боль¬ 
шинстве конвейерных конструкций считанная команда должна быть выполнена, 
даже если в предыдущей команде был принят условный переход. У разработчи¬ 
ков компиляторов и операционных систем это свойство конвейеров часто вызы¬ 
вает головную боль. 

Более передовым по сравнению с конвейерной конструкцией является супер¬ 
скалярный центральный процессор, продемонстрированный на рис. 1.6, б. В этой 
структуре присутствует множество выполняющих узлов: один для целочисленных 
арифметических операций, второй — для операций с плавающей точкой и еще 
один — для логических операций. За один такт считывается две или более коман¬ 
ды, которые декодируются и сбрасываются в буфер хранения, где они ждут своей 
очереди на выполнение. Когда выполняющее устройство освобождается, оно за¬ 
глядывает в буфер хранения, интересуясь, есть ли там команда, которую оно может 
обработать, и если да, то забирает ее и выполняет. В результате команды часто ис¬ 
полняются не в порядке их следования. В большинстве случаев аппаратура долж¬ 
на гарантировать, что результат совпадет с тем, который выдала бы последователь¬ 
ная конструкция. Однако, как мы увидим в дальнейшем, при этом подходе весьма 
неприятные усложнения коснулись и операционной системы. 
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а 



Рис. 1.6. Конвейер с тремя стадиями (а); суперскалярный процессор (б) 

Большинство центральных процессоров, кроме очень простых, используемых 
во встроенных системах, имеют два режима работы: режим ядра и пользователь¬ 
ский режим. Обычно режим задается битом слова состояния процессора (регистра 
Р5\Ѵ). Если процессор запущен в режиме ядра, он может выполнять все команды 
из набора инструкций и использовать все возможности аппаратуры. Операцион¬ 
ная система работает в режиме ядра, предоставляя доступ ко всему оборудованию. 

В противоположность этому программы пользователей работают в пользова¬ 
тельском режиме, разрешающем выполнение подмножества команд и делающем 
доступным лишь часть аппаратных средств. Как правило, все команды, включая 
ввод-вывод данных и защиту памяти, запрещены в пользовательском режиме. 
Установка бита режима ядра в регистре Р5\Ѵ, естественно, недоступна. 

Для связи с операционной системой пользовательская программа должна сфор¬ 
мировать системный вызов, который обеспечивает переход в режим ядра и акти¬ 
визирует функции операционной системы. Команда ТКАР (эмулированное преры¬ 
вание) переключает режим работы процессора из пользовательского в режим ядра 
и передает управление операционной системе. После завершения работы управле¬ 
ние возвращается к пользовательской программе, к команде, следующей за систем¬ 
ным вызовом. Мы рассмотрим в деталях процесс системных вызовов позже в этой 
главе. В дальнейшем для выделения системных вызовов в тексте мы будем исполь¬ 
зовать такой же шрифт, как в этом слове: геасі. 

Стоит отметить, что в компьютерах, помимо инструкций для выполнения сис¬ 
темных вызовов, есть и другие прерывания. Большинство этих прерываний вызы¬ 
ваются аппаратно для предупреждения об исключительных ситуациях, таких как 
попытка деления на ноль или переполнение при операциях с плавающей точкой. 
Во всех подобных случаях управление переходит к операционной системе, кото- 
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рая должна решать, что делать дальше. Иногда нужно завершить программу с со¬ 
общением об ошибке. В других случаях ошибку можно проигнорировать (напри¬ 
мер, при потере значимости числа его можно принять равным нулю). Наконец, 
если программа объявила заранее, что требуется обработать некоторые виды ус¬ 
ловий, управление может вернуться назад к программе, позволяя ей самой разре¬ 
шить появившуюся проблему. 


Память 

Второй основной составляющей любого компьютера является память. В идеале 
память должна быть максимально быстрой (быстрее, чем обработка одной инструк¬ 
ции, чтобы работа центрального процессора не замедлялась обращениями к памя¬ 
ти), достаточно большой и чрезвычайно дешевой. На данный момент не существу¬ 
ет технологий, удовлетворяющих всем этим требованиям, поэтому используется 
другой подход. Системы памяти конструируются в виде иерархии слоев, как 
показано на рис. 1.7. 

Верхний слой состоит из внутренних регистров центрального процессора. Они 
сделаны из того же материала, что и процессор, и так же быстры, как и сам процес¬ 
сор. Поэтому при доступе к ним обычно не возникает задержек. Внутренние регист¬ 
ры предоставляют возможность для хранения 32 х 32 бит на 32-разрядном процес¬ 
соре и 64 х 64 бит на 64-разрядном процессоре. Это составляет меньше одного 
килобайта в обоих случаях. Программы сами могут управлять регистрами (то есть 
решать, что в них хранить) без вмешательства аппаратуры. 

В следующем слое находится кэш-память, в основном контролируемая обо¬ 
рудованием. Оперативная память разделена на кэш-строки, обычно по 64 байт, 
с адресацией от 0 до 63 в нулевой строке, от 64 до 127 в первой строке и т. д. Наи¬ 
более часто используемые строки кэша хранятся в высокоскоростной кэш-памя¬ 
ти, расположенной внутри центрального процессора или очень близко к нему. Ког¬ 
да программа должна прочитать слово из памяти, кэш-микросхема проверяет, есть 
ли нужная строка в кэше. Если это так, то происходит результативное обращение 
к кэш-памяти, запрос удовлетворяется целиком из кэша и запрос к памяти на шину 
не выставляется. Удачное обращение к кэшу, как правило, по времени занимает 
около двух тактов, а неудачное приводит к обращению к памяти с существенной 
потерей времени. Кэш-память ограничена в размере, что обусловлено ее высокой 
стоимостью. В некоторых машинах есть два или даже три уровня кэша, причем 
каждый последующий медленнее и больше предыдущего. 

Среднее время доступа Средний объем 


1 нс 

2 нс 
10 нс 
10 мс 
100 с 



<1 Кбайт 
1 Мбайт 
64—512 Мбайт 
5—50 Гбайт 
20—100 Гбайт 


Рис. 1.7. Типичная иерархическая структура памяти. Числа приблизительны 
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Далее следует оперативная память. Это главная рабочая область запоминаю¬ 
щего устройства машины. Оперативную память часто называют ОЗУ (оператив¬ 
ное запоминающее устройство, в англоязычной литературе НАМ, Капсіош Ассезз 
Метогу — память с произвольным доступом). Раньше иногда ее называли соге 
тетогу — запоминающее устройство на магнитных сердечниках, поскольку в 50-е 
и 60-е годы в компьютерах для оперативной памяти использовали крошечные 
намагничиваемые ферритовые сердечники. Сейчас память составляет десятки 
и сотни мегабайт и растет с потрясающей скоростью. Все запросы центрального 
процессора, которые не могут быть выполнены кэш-памятью, поступают для об¬ 
работки в основную память. 

Следующим в продемонстрированной на рисунке структуре идет магнитный 
диск (жесткий диск). Дисковая память на два порядка дешевле ОЗУ в пересчете 
на бит и зачастую на два порядка больше по величине. У диска есть только одна 
проблема: случайный доступ к данным на нем занимает примерно на три порядка 
больше времени. Причиной низкой скорости жесткого диска является тот факт, 
что диск представляет собой механическую конструкцию, устройство которой про¬ 
демонстрировано на рис. 1.8. 


Поверхность 


Поверхность 

Поверхность 


Поверхность 

Поверхность 


Поверхность 

Поверхность 


Поверхность 



Рис. 1.8. Устройство жесткого диска 

Жесткий диск состоит из одной или нескольких металлических пластин, вра¬ 
щающихся со скоростью 5400, 7200 или 10 800 оборотов в минуту. Механическая 
вилка поворачивается над дисками подобно звукоснимателю на старых граммо¬ 
фонах для проигрывания виниловых пластинок на скорости 33 оборота в минуту. 
Информация записывается на пластины в виде концентрических окружностей. 
Головки в каждой заданной позиции вилки могут прочитать кольцо на пластине, 
называемое дорожкой. Все вместе дорожки для заданной позиции вилки форми¬ 
руют цилиндр. 

Каждая дорожка разделена на некоторое количество секторов, обычно по 
512 байт на сектор. На современных дисках внешние цилиндры содержат большее 
количество секторов, чем внутренние. Перемещение головки от одного цилиндра 
к другому занимает около 1 мс, а перемещение к произвольному цилиндру требует 
от 5 до 10 мс, в зависимости от диска. Когда головка располагается над правильной 
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дорожкой, нужно ждать, пока двигатель повернет диск так, чтобы под головкой 
встал требуемый сектор. Это занимает дополнительно от 5 до 10 мс, в зависимости 
от скорости вращения диска. Дальше, когда сектор уже находится под головкой, 
процесс чтения или записи происходит со скоростью от 5 Мбайт/с для низкоско¬ 
ростных дисков до 160 Мбайт/с для самых высокоскоростных. 

Последний слой в пирамиде памяти занимает магнитная лента. Этот носитель 
часто используется для создания резервных копий пространства жесткого диска 
или для хранения очень больших наборов данных. Для доступа к информации на 
ленте ее сначала нужно поместить в устройство для чтения магнитных лент — это 
может делать человек или робот (автоматическое управление лентами обычно ис¬ 
пользуется при работе с огромными базами). Затем лента перематывается до запра¬ 
шиваемого блока с информацией. Весь процесс может длиться минуты. Большой 
плюс лент заключается в том, что они крайне дешевы и мобильны. Это очень важно 
для резервных копий, которые нужно содержать отдельно, чтобы они сохранились 
после стихийных бедствий, например пожаров, наводнений, землетрясений и т. д. 

Описанная нами иерархия памяти достаточно типична, но в некоторых вари¬ 
антах могут присутствовать не все уровни или несколько другие их виды (напри¬ 
мер, оптический диск). В любом случае при движении по иерархии сверху вниз 
время произвольного доступа значительно увеличивается от устройства к устрой¬ 
ству, вместимость растет эквивалентно времени доступа, а стоимость одного бита 
информации падает столь же быстрыми темпами. Поэтому вполне вероятно, что 
такая структура памяти будет популярна еще долгие годы. 

Кроме описанных выше видов во многих компьютерах есть небольшое количе¬ 
ство постоянной памяти с произвольным доступом — в отличие от оперативной 
памяти, она не теряет свое содержимое при выключении энергии машины. ПЗУ 
(постоянное запоминающее устройство, КОМ, Кеай Опіу Мешогу — память толь¬ 
ко для чтения) программируется в процессе производства и после этого его содер¬ 
жимое нельзя изменить. Такая память достаточно быстра и дешева. На некоторых 
компьютерах программы начальной загрузки, используемые при запуске компью¬ 
тера, находятся в ПЗУ. Кроме того, некоторые карты ввода-вывода содержат ПЗУ 
для управления низкоуровневыми устройствами. 

Электрически стираемое ПЗУ (БЕРКОМ, Еіесігісаііу ЕгазаЫе КОМ) и флэш- 
ОЗУ (КазЬ КАМ) также энергонезависимы, но в отличие от ПЗУ их содержимое 
можно стереть и переписать. Однако запись данных на них требует намного боль¬ 
ше времени, чем запись в оперативную память. Поэтому они используются точно 
так же, как и ПЗУ. Дополнительное преимущество электрически стираемого ПЗУ 
и флэшОЗУ состоит в том, что с их помощью теперь можно исправить ошибки, 
содержащиеся в программах. 

Существует еще один вид памяти, называемый СМОЗ и являющийся энерго- 
зависимым. Во многих компьютерах СМОЗ-память используется для хранения 
текущих даты и времени. СМОЗ-память и часовая микросхема, отвечающая за от¬ 
счет времени, получают питание от маленького аккумулятора, поэтому компью¬ 
тер всегда показывает правильное время, даже если он был выключен. СМОЗ так¬ 
же может содержать конфигурационные параметры, например указание, с какого 
жесткого диска производить загрузку. СМОЗ-память используется для этих целей, 
так как она потребляет настолько мало энергии, что установленный на фабрике 
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аккумулятор часто работает в течение нескольких лет. Однако если аккумулятор 
начинает выходить из строя, можно подумать, что компьютер стал страдать болез¬ 
нью Альцгеймера и забывает то, о чем он помнил годами (например, с какого жест¬ 
кого диска загружать систему). 

Теперь более внимательно рассмотрим основную часть оперативной памяти. 
Зачастую крайне желательно держать сложные программы в памяти целиком. 
Если, например, одна программа находится в заблокированном состоянии, ожи¬ 
дая окончания операции чтения данных с диска, то другая программа может в это 
время использовать центральный процессор, что улучшает показатели эксплуата¬ 
ции процессора. Но при одновременном нахождении в памяти нескольких про¬ 
грамм возникает необходимость решения двух следующих проблем: 

1. Как защитить программы друг от друга, а ядро системы от всех них? 

2. Как управлять перемещением программ в памяти? 

Возможны различные решения этих вопросов. Но все они предполагают снаб¬ 
жение процессора специальным оборудованием. 

Первая проблема достаточно очевидна, но второй вопрос требует пояснения. 
В процессе компилирования и компоновки программы компилятор и компонов¬ 
щик не знают, в какую область физической памяти будет загружена программа 
после завершения процесса. По этой причине они обычно предполагают, что про¬ 
грамма начнется с адреса 0, и помещают туда первую инструкцию. Предположим, 
что первая инструкция считывает из памяти слово, имеющее адрес 10 000, а вся 
программа и данные к ней были загружены, начиная с адреса 50 000. Тогда при 
выполнении первой команды появится сообщение об ошибке, поскольку она будет 
ссылаться на слово по адресу 10 000 вместо 60 000. Для решения этой проблемы нам 
нужно или «релоцировать» программу во время загрузки, то есть настроить ее, 
находя все адреса и изменяя их в соответствии с реальной адресацией (это выпол¬ 
нимо, но дорого), или оперативно изменять адресацию во время работы программы. 

Простейшее решение показано на рис. 1.9, а. На рисунке видно, что компьютер 
оборудован двумя специальными регистрами: базовым и предельным. (Заметим, 
что в этой книге числа, начинающиеся с 0х, являются шестнадцатеричными в со¬ 
ответствии с правилами орфографии языка С, а числа, начинающиеся с нуля — 
восьмеричными.) Когда программа начинает работать, в базовый регистр загружа¬ 
ется адрес начала исполняемого модуля программы, а предельный регистр говорит, 
о том, сколько занимает исполняемый модуль программы вместе с данными. При 
выборке команды из памяти аппаратура проверяет счетчик команд, и если он меньше, 
чем предельный регистр, то добавляет к нему значение базового регистра, а сумму 
передает памяти. Когда программа хочет прочитать слово данных (например, из 
адреса 10 000), аппаратура автоматически добавляет к этому адресу содержимое 
базового регистра (например, 50 000) и передает сумму (60 000) памяти. Базовый 
регистр дает возможность программе ссылаться на любую часть памяти, следующую 
за хранящимся в нем адресом. Кроме того, предельный регистр запрещает програм¬ 
ме обращение к любой части памяти после программы. Таким образом, с помощью 
этой схемы решаются обе задачи: защиты и перемещения программ. Стоимость 
решения равна двум новым регистрам и незначительному увеличению времени, 
затрачиваемого на операцию (уходящего на проверку предела и суммирование). 
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Адреса 

Регистры 



Рис. 1.9. Используется одна пара база—предел. Программа имеет доступ к части памяти, 
находящейся между базой и пределом (а); используются две пары база—предел. Код программы 
находится между базой 1 и пределом 1, а данные к ней — между базой 2 и пределом 2 (б) 

В результате проверки и преобразования данных адрес, сформированный програм¬ 
мой и называемый виртуальным, переводится в адрес, используемый памятью и на¬ 
зываемый физическим. Устройство, которое выполняет проверку и преобразование, 
называется устройством управления памятью или диспетчером памяти (М№Ш, 
Мешогу Мапа§ешепІ ІІпй). Диспетчер памяти располагается или в схеме процес¬ 
сора, или близко к ней, но логически находится между процессором и памятью. 

Более сложный диспетчер памяти показан на рис. 1.9, 6. Здесь диспетчер памя¬ 
ти состоит из двух пар базового и предельных регистров: одна пара для текста 
программы, другая — для данных. Командный регистр и все другие ссылки на текст 
программы работают с парой 1, а ссылки на данные используют пару 2. Появля¬ 
ется возможность делить одну и ту же программу между несколькими пользо¬ 
вателями и при этом хранить в памяти только одну копию программы, что было 
невозможно в первой схеме. Когда работает программа 1, четыре регистра распо¬ 
ложены так, как показано стрелками на рис. 1.9, б слева. При работе программы 2 
они располагаются так, как показано стрелками на рисунке справа. На самом 
деле существуют намного более сложные диспетчеры памяти, мы изучим их 
позже в этой книге. А сейчас нужно запомнить, что управление диспетчером 
памяти должно быть функцией операционной системы, так как нет уверенности, 
что пользователь сделает это корректно. 

На характеристики памяти в основном влияют два аспекта. Во-первых, кэш 
скрывает относительно низкую скорость памяти. После того как программа про- 
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работала некоторое время, кэш заполняется строками программы, увеличивая ско¬ 
рость. Однако когда операционная система переключается от одной программы к 
другой, кэш остается заполненным данными первой программы, а необходимые 
строки новой программы должны загружаться уже из физической памяти. Такая 
операция может стать главной причиной снижения производительности, если она 
происходит слишком часто. 

Во-вторых, при переключении от одной программы к другой регистры управле¬ 
ния памятью должны меняться. На рис. 1.9, б требуется перезагрузка только четы¬ 
рех регистров, что не является серьезной проблемой, но в реальных диспетчерах 
памяти должно перезагружаться, явно или динамически, намного большее коли¬ 
чество регистров. В любом случае подобная операция занимает некоторое время. 
Мораль этой истории такова: переключение от одной программы к другой, назы¬ 
ваемое переключением контекста, очень дорого. 

Устройства ввода-вывода 

Память не является единственным ресурсом, которым должна управлять операци¬ 
онная система. Устройства ввода-вывода также тесно взаимодействуют с операци¬ 
онной системой. Как видно из рис. 1.5, устройства ввода-вывода обычно состоят 
из двух частей: контроллера и самого устройства. Контроллер — это микросхема 
или набор микросхем на вставляемой в разъем плате, физически управляющая 
устройством. Он принимает команды операционной системы, например указание 
прочитать данные с устройства, и выполняет их. 

Во многих случаях фактическое управление устройством очень сложно и тре¬ 
бует высокого уровня детализации, поэтому в работу контроллера входит пред¬ 
ставление простого интерфейса для операционной системы. Контроллер диска 
может принять команду прочесть сектор 11 206 с диска 2. При этом контроллер 
должен преобразовать линейный номер сектора в номер цилиндра, сектора и го¬ 
ловки. Операция преобразования усложняется тем фактом, что внешние цилинд¬ 
ры могут иметь больше секторов, чем внутренние, и что номера испорченных сек¬ 
торов отображаются на другие секторы. Затем контроллер должен определить, над 
каким цилиндром находится в данный момент головка, и дать ей последователь¬ 
ность импульсов, чтобы переместить ее на необходимое количество цилиндров. 
Дальше нужно ждать, пока повернется диск, поместив требуемый сектор под го¬ 
ловку. Затем начинается чтение и сохранение битов по мере поступления их с дис¬ 
ка, удаление заголовка и вычисление контрольной суммы. Наконец, контроллер 
должен собрать полученные биты в слова и сохранить их в памяти. Для осуществ¬ 
ления всей этой работы контроллеры часто содержат маленькие встроенные ком¬ 
пьютеры, запрограммированные на выполнение подобных задач. 

Следующей частью является само устройство. Устройства имеют достаточно 
простые интерфейсы, во-первых, потому что их возможности весьма невелики и, 
во-вторых, потому что нужно привести их к единому стандарту. Единый стандарт 
необходим, чтобы любой ШЕ-контроллер диска мог управлять любым ШЕ-дис- 
ком. Аббревиатура ШЕ образована от ІпІе§гаІе<і Огіѵе Еіесігопісз (встроенный 
интерфейс накопителей). ГОЕ-интерфейс является стандартным для дисков на 
компьютерах с процессором Репііиш, а также некоторых других компьютерах. 
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Поскольку настоящий интерфейс устройства скрыт с помощью контроллера, опе¬ 
рационная система видит только интерфейс контроллера, который может сильно 
отличаться от интерфейса самого устройства. 

Так как все типы контроллеров отличаются друг от друга, для управления ими 
требуется различное программное обеспечение. Программа, которая общается с кон¬ 
троллером, отдает ему команды и получает ответы, называется драйвером устрой¬ 
ства. Каждый производитель контроллеров должен поставлять драйверы для под¬ 
держиваемых им операционных систем. Вы можете купить сканер с драйверами 
для \УтсІо\ѵ5 98, \УтсІо\ѵ5 2000 и ІЛМІХ. Если вы хотите получить возможность 
использовать драйвер, его нужно установить в операционную систему так, чтобы 
он мог работать в режиме ядра. Теоретически драйверы могут работать вне ядра, 
но такую возможность поддерживают всего несколько существующих систем, гак 
как для этого требуется, чтобы драйвер в пространстве пользователя имел доступ 
к устройству неким контролируемым способом — очень редко поддерживаемое 
свойство. Есть три способа установки драйвера в ядро. Первый заключается в том, 
чтобы заново скомпоновать ядро вместе с новым драйвером и затем перезагрузить 
систему. Так работает множество систем ІЛМІХ. Второй: создать запись во входя¬ 
щем в операционную систему файле, говорящую о том, что требуется драйвер, и за¬ 
тем перезагрузить систему. Во время начальной загрузки операционная система 
сама находит нужные драйверы и загружает их. Так работает система \Ѵіпс1о\ѵ5. 
При третьем способе операционная система может принимать новые драйверы, не 
прерывая работы, и оперативно устанавливать их, не нуждаясь при этом в переза¬ 
грузке. Этот способ редко используется, но сейчас он становится все более и более 
распространенным. Такие съемные устройства, как шины ІІ5В и ІЕЕЕ 1394 (мы 
поговорим о них ниже), всегда нуждаются в динамически загружаемых драйверах. 

Для связи с каждым контроллером существует небольшое количество регист¬ 
ров, Например, минимальный контроллер диска может иметь регистры для опре¬ 
деления адреса на диске, адреса в памяти, номер сектора и направления операции 
(чтение или запись). Чтобы активизировать контроллер, драйвер получает коман¬ 
ду от операционной системы, затем транслирует ее в величины, подходящие для 
записи в регистры устройства. 

На некоторых компьютерах регистры устройств отображаются в адресное про¬ 
странство операционной системы, поэтому их можно читать или записывать как 
обычные слова в памяти. На таких машинах не нужны специальные команды вво¬ 
да-вывода, а программы пользователей можно оградить от аппаратуры, помещая 
эти адреса в памяти за пределами досягаемости программ (например, с помощью 
базового и предельного регистров). На других компьютерах регистры устройств 
располагаются в специальных портах ввода-вывода, и каждый регистр имеет свой 
адрес порта. На этих машинах в режиме работы ядра доступны команды І№ и 01ІТ, 
они позволяют драйверам считывать и записывать регистры. Первая схема устра¬ 
няет необходимость специальных команд ввода-вывода, но использует некоторое 
количество адресного пространства. Вторая схема не затрагивает адресное простран¬ 
ство, но требует наличие специальных команд. Обе схемы широко используются. 

Ввод и вывод данных можно осуществлять тремя различными способами. Про¬ 
стейший метод состоит в том, что пользовательская программа выдает системный 
запрос, который ядро транслирует в вызов процедуры соответствующего драйве- 
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ра. Затем драйвер начинает процесс ввода-вывода. В это время драйвер выполня¬ 
ет очень короткий программный цикл, постоянно опрашивая готовность устрой¬ 
ства, с которым он работает (обычно есть некий бит, который указывает на то, что 
устройство все еще занято). По завершении операции ввода-вывода драйвер по¬ 
мещает данные туда, куда требуется, и возвращается в исходное состояние. Затем 
операционная система возвращает управление программе, осуществлявшей вызов. 
Этот метод называется ожиданием готовности или активным ожиданием и имеет 
один недостаток: процессор должен опрашивать устройство до тех пор, пока оно 
не завершит свою работу. 

При втором способе драйвер запускает устройство и просит его выдать прерыва¬ 
ние по окончании ввода-вывода. После этого драйвер возвращает данные, операци¬ 
онная система блокирует программу вызова, если это нужно, и начинает выпол¬ 
нять другие задания. Когда контроллер обнаруживает окончание передачи данных, 
он генерирует прерывание, чтобы сигнализировать о завершении операции. 

Прерывания очень важны в работе операционной системы, поэтому рассмот¬ 
рим это понятие более внимательно. На рис. 1.10, а показан трехшаговый процесс 
ввода-вывода. На первом шаге драйвер передает команду контроллеру, записывая 
информацию в регистры устройства. Затем контроллер запускает устройство. 
Когда контроллер заканчивает чтение или запись того количества байтов, которое 
ему было указано передать, он посылает сигнал микросхеме контроллера пре¬ 
рываний, используя определенные провода шины, — это шаг 2. На шаге 3, если 
контроллер прерываний готов к приему прерывания (а этого может и не быть, если 
он занят прерыванием более высокого приоритета), то он подает сигнал на оп¬ 
ределенный контакт процессора, таким образом информируя центральный процес¬ 
сор. На шаге 4 контроллер прерываний выставляет номер устройства на шину так, 
чтобы центральный процессор мог прочесть его и узнать, какое устройство только 
что завершило свою работу (ведь в одно и то же время могут работать несколько 
устройств). 
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Рис. 1.10. Действия, выполняемые при запуске устройства ввода-вывода и получении 
прерывания (а); обработка прерывания включает в себя получение прерывания, 
переход к обработчику прерываний и возврат к программе пользователя (б) 
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Как только центральный процессор решил принять прерывание, содержимое 
счетчика команд (РС) и слова состояния процессора (Р5\Ѵ) помещается в теку¬ 
щий стек, а процессор переключается в режим работы ядра. Номер устройства мо¬ 
жет использоваться как индекс части памяти, служащий для поиска адреса обра¬ 
ботчика прерываний данного устройства. Эта часть памяти называется вектором 
прерываний. Когда обработчик прерываний (это часть драйвера устройства, по¬ 
славшего прерывание) начинает свою работу, он удаляет расположенные в стеке 
счетчик команд и слово состояния процессора, сохраняет их и запрашивает уст¬ 
ройство, чтобы получить информацию о его состоянии. После того как обработка 
прерывания целиком завершена, управление возвращается к работавшей до этого 
программе пользователя, к той команде, выполнение которой еще не было закон¬ 
чено. Описанные шаги показаны на рис. 1.10, б. 

Третий метод ввода-вывода информации заключается в использовании специ¬ 
ального контроллера прямого доступа к памяти (ОМА, Эпесі: Метогу Ассезз), 
который управляет потоком битов между оперативной памятью и некоторыми 
контроллерами без постоянного вмешательства центрального процессора. Процес¬ 
сор вызывает микросхему ЭМА, говорит ей, сколько байтов нужно передать, со¬ 
общает адреса устройства и памяти, а также направление передачи данных и по¬ 
зволяет дальше действовать ей самой. По завершении работы ЭМА инициирует 
прерывание, которое обрабатывается так же, как было описано выше. Контроллер 
ЭМА и аппаратура ввода-вывода более детально будут обсуждаться в главе 5. 

Прерывания часто происходят в очень неподходящие моменты, например во 
время обработки другого прерывания. По этой причине центральный процессор 
обладает возможностью запрещать прерывания и разрешать их позже. Пока преры¬ 
вания запрещены, все устройства, завершившие работу, продолжают посылать свои 
сигналы, но работа процессора не прерывается до тех пор, пока прерывания не будут 
разрешены. Если заканчивают работу сразу несколько устройств в то время, когда 
прерывания запрещены, контроллер прерываний решает, какое из них должно 
быть обработано первым, обычно основываясь на статических приоритетах, назна¬ 
ченных для каждого устройства. Устройство с высшим приоритетом побеждает. 


Шины 

Структура, показанная на рис. 1.5, в течение многих лет использовалась на мини¬ 
компьютерах, а также на первых моделях ІВМ РС. Но поскольку процессоры и па¬ 
мять стали работать быстрее, возможности одной шины (и, конечно, шины ІВМ РС) 
по управлению всей передачей данных достигли своего предела. Нужно было 
что-то делать. В результате в систему добавились дополнительные шины как для 
ускорения общения с устройствами ввода-вывода, так и для пересылки данных 
между процессором и памятью. Вследствие этой эволюции сейчас большая систе¬ 
ма Репііит выглядит примерно так, как изображено на рис. 1.11. 

У этой системы восемь шин (шина кэша, локальная шина, шина памяти, РСІ, 
5С5І, ІІ5В, ГОЕ и І5А), каждая со своей скоростью передачи данных и своими 
функциями. В операционной системе для управления компьютером и его конфи¬ 
гурации должны находиться сведения обо всех этих шинах. Две основные шины — 
это І8А (Іпсішігу Зіапсіагсі АгсЬйесШге — промышленная стандартная архитекту- 
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ра), оригинальная шина компьютера ІВМ РС, и ее преемник, шина РСІ (РегірЬегаІ 
Сошропепі Іпіегсоппесі — интерфейс периферийных устройств). Шина І5А впер¬ 
вые появилась на компьютерах ІВМ РС/АТ, она работает на частоте 8,33 МГц 
и может передавать два байта за такт с максимальной скоростью 16,67 Мбайт/с. 
Она включена в систему для обратной совместимости со старыми медленными 
платами ввода-вывода. Шина РСІ была создана компанией Іпіеі в качестве пре¬ 
емницы шины І5А. Она может работать на частоте 66 МГц и передавать сразу по 
8 байт за такт со скоростью 528 Мбайт/с. Сейчас большинство высокоскоростных 
устройств ввода-вывода используют шины РСІ. Даже некоторые компьютеры с 
процессорами, отличными от Іпіеі, пользуются шиной РСІ, поскольку с ней со¬ 
вместимо очень много плат ввода-вывода. 

При такой конфигурации центральный процессор по локальной шине переда¬ 
ет данные микросхеме РСІ-моста, который, в свою очередь, обращается к памяти 
по выделенной шине памяти, часто работающей на частоте 100 МГц. Системы 
Репіішп имеют кэш первого уровня (кэш ІЛ), встроенный в процессор, и намного 
больший внешний кэш второго уровня (кэш Е2), подключенный к процессору от¬ 
дельной шиной кэша. 
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Рис. 1.11. Структура большой системы Репііит 

Кроме того, в систему входят три специализированные шины: ГОЕ, ГГ5В и 5С5І. 
Шина ГОЕ служит для присоединения периферийных устройств к системе — дис¬ 
ков и устройств для чтения компакт-дисков (СБ-КОМ). ГОЕ-шина — это потомок 
интерфейса контроллера диска на РС/АТ, и сейчас она входит в стандартный 
комплект всех систем, основанных на процессорах Репішгп. 
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Шина ІІ8В (ІІпіѵегзаІ Зегіаі Виз — универсальная последовательная шина) 
была придумана для того, чтобы присоединить к компьютеру все медленные уст¬ 
ройства ввода-вывода, такие как клавиатура и мышь. Она использует маленький 
четырехпроводной разъем, причем два провода поставляют электропитание к 
ІІ5В-устройствам. ЕГ5В — это централизованная шина, по которой главное устрой¬ 
ство каждую миллисекунду опрашивает устройства ввода-вывода, чтобы узнать, есть 
ли у них данные. Она может управлять загрузкой данных со скоростью 1,5 Мбайт/с. 
Все ІІ5В-устройства используют один драйвер, избавляя нас тем самым от необхо¬ 
димости установки новых драйверов для каждого нового ІІ5В-устройства. Поэто¬ 
му 115В-устройства можно присоединять к системе без ее перезагрузки. 

8С8І (Зшаіі Сотрпіег Зузіеш Іпіегіасе — системный интерфейс малых компь¬ 
ютеров) — это высокопроизводительная шина, применяемая для быстрых дисков, 
сканеров и других устройств, нуждающихся в значительной пропускной способ¬ 
ности. Ее производительность достигает 160 Мбайт/с. ШинаЗСЗІ используется 
в системах Масіпіозіі с момента их появления, кроме того, она популярна в ІЖІХ- 
системах и некоторых системах на базе процессоров Іпіеі. 

Есть еще одна шина (не показанная на рис. 1.11), называется ІЕЕЕ 1394. Иног¬ 
да ее также называют РігеѴѴіге, хотя, строго говоря, РігеѴѴіге — это название, дан¬ 
ное компанией Арріе собственной реализации шины 1394. Как и И5В, ІЕЕЕ 1394 
является бит-последовательной шиной, но она поддерживает пакетную передачу 
данных со скоростью, достигающей 50 Мбайт/с. Это ее свойство позволяет под¬ 
ключать к компьютеру портативные цифровые видеокамеры и тому подобные 
мультимедийные устройства. В отличие от И5В шина ІЕЕЕ 1394 не имеет цент¬ 
рального контроллера. Шины 5С5І и ІЕЕЕ 1394 конкурируют с разработанной 
более быстрой версией шины И5В. 

Работая в окружении, изображенном на рис. 1.11, операционная система долж¬ 
на уметь распознавать аппаратные составляющие и уметь их настраивать. Это тре¬ 
бование привело компании Іпіеі и МісгозоЙ к разработке системы персонального 
компьютера, называемой р1и§ аікі ріау («включи и работай»). В основе этой сис¬ 
темы лежала концепция, близкая к той, что была впервые реализована компанией 
Арріе МасіпГояЬ. До появления р!и§ апб ріау каждая плата ввода-вывода имела 
фиксированные адреса регистров ввода-вывода и уровень запроса прерывания. 
Например, клавиатура использовала прерывание 1 и адреса в диапазоне от 0x60 
до 0x64; контроллер гибкого диска использовал прерывание 6 и адреса от ОхЗРО 
до 0хЗР7; принтер пользовался прерыванием 7 и адресами от 0x378 до 0х37А и т. д. 

Все в этой схеме было хорошо до тех пор, пока пользователь не покупал зву¬ 
ковую карту и модем, и оказывалось, что оба устройства случайно использовали, 
скажем, прерывание 4. В таком случае они конфликтовали и не могли работать 
вместе. Возможным решением было встроить набор ЭІР-переключателей или 
джамперов (рппрег — перемычка) в каждую плату и объяснить пользователю не¬ 
обходимость настройки каждой платы таким образом, чтобы адреса портов и но¬ 
мера прерываний различных устройств не конфликтовали друг с другом. Подро¬ 
стки, посвятившие свою жизнь изучению тонкостей аппаратуры персонального 
компьютера, иногда могут сделать зто без ошибок. К сожалению, кроме них это 
практически никому не удавалось, что приводило к полному хаосу. 
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Глава 1. Введение 


Стандарт р1и§ апсі ріау позволяет системе автоматически собирать информа¬ 
цию об устройствах ввода-вывода, централизованно назначать уровни прерыва¬ 
ния и адреса ввода-вывода, а затем сообщать каждой плате эту информацию — вот 
краткое описание процесса. Такая система работает на компьютерах Репішт. Каж¬ 
дый компьютер с процессором Репііит содержит материнскую плату (в США бла¬ 
годаря успехам борьбы за политическую корректность эту плату теперь решено 
называть родительской). На материнской плате находится программа, называемая 
системой ВЮ8 (Вазіс Іприі Оиіриі ЗуЫет — базовая система ввода-вывода). 
ВЮ5 содержит программы ввода-вывода низкого уровня, включая процедуры для 
чтения с клавиатуры, вывода информации на экран, ввода-вывода данных с диска 
и т. д. В настоящее время эти функции хранятся во флзш-ОЗУ, которая в обыч¬ 
ных условиях является неизменяемой, но, если в ВЮ5 нашлись какие-либо ошиб¬ 
ки, ее может изменить операционная система. 

При начальной загрузке компьютера стартует система ВЮ5. Сначала она про¬ 
веряет количество установленной в системе оперативной памяти, подключены ли 
клавиатура и другие основные устройства и корректно ли они отзываются. ВЮ5 
начинает проверку с шин І5А и РСІ, чтобы определить все устройства, присоеди¬ 
ненные к ним. Некоторые из этих устройств являются традиционными, их также 
называют унаследованными (Іе^асу), то есть созданными до изобретения р1и§ апсі 
ріау. Они имеют фиксированные уровни прерывания и адрес порта ввода-вывода 
(например, заданные с помощью переключателей или перемычек на плате ввода- 
вывода без возможности их изменения операционной системой). Эти устройства 
регистрируются. Устройства р1и§ апсі ріау тоже регистрируются. Если присутству¬ 
ющие устройства отличаются от тех, что были во время последней загрузки, кон¬ 
фигурируются новые устройства. 

Затем ВЮ5 определяет устройство, с которого будет происходить загрузка, по 
очереди пробуя каждое из списка, хранящегося в СМОЗ-памяти. Пользователь 
может изменить этот список, войдя в конфигурационную программу ВЮ5 сразу 
после загрузки. Обычно сначала делается попытка загрузиться с гибкого диска. 
Если это не удается, пробуется компакт-диск. Если в компьютере отсутствуют 
и гибкий диск, и компакт-диск, система загружается с жесткого диска. С загру¬ 
зочного устройства считывается в память и выполняется первый сектор. В этом 
секторе находится программа, обычно проверяющая таблицу разделов в конце 
загрузочного сектора, чтобы определить, который из разделов является активным. 
Затем из того же раздела читается вторичный загрузчик. Он считывает из актив¬ 
ного раздела операционную систему и запускает ее. 

После этого операционная система опрашивает ВІ05, чтобы получить инфор¬ 
мацию о конфигурации компьютера. Для каждого устройства она проверяет на¬ 
личие драйвера. Если драйвер отсутствует, операционная система просит пользо¬ 
вателя вставить гибкий диск или компакт-диск, содержащий драйвер (эти диски 
поставляются производителем устройства). Если же все драйверы на месте, опе¬ 
рационная система загружает их в ядро. Затем она инициализирует таблицы драй¬ 
веров, создает все необходимые фоновые процессы и запускает программу ввода 
пароля или графический интерфейс на каждом терминале. По крайней мере, пред¬ 
полагается, что операционная система должна работать таким образом. В реаль¬ 
ной жизни система р1и§ апсі ріау часто бывает настолько ненадежна, что многие 
люди называют ее р!и§ апсі ргау («включи и молись»). 
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Понятия операционной системы 

Для каждой операционной системы существует набор базовых понятий, например 
процессы, память и файлы, которые являются самыми важными для понимания 
общей идеи. В следующих разделах мы рассмотрим некоторые из них по возмож¬ 
ности кратко, как это должно быть сделано во введении. Позже мы вернемся к каж¬ 
дому из них и рассмотрим в деталях. Для иллюстрации этих понятий время от 
времени мы будем использовать примеры, в основном взятые из системы ІЖІХ. 
Но аналогичные примеры можно найти и в других системах. 


Процессы 

Ключевое понятие операционной системы — процесс. Процессом, по существу, 
называют программу в момент выполнения. С каждым процессом связывается 
его адресное пространство — список адресов в памяти от некоторого минимума 
(обычно нуля) до некоторого максимума, которые процесс может прочесть и в ко¬ 
торые он может писать. Адресное пространство содержит саму программу, данные 
к ней и ее стек. Со всяким процессом связывается некий набор регистров, включая 
счетчик команд, указатель стека и другие аппаратные регистры, плюс вся осталь¬ 
ная информация, необходимая для запуска программы. 

Мы более детально рассмотрим понятие процесса в главе 2, но сейчас для 
того, чтобы интуитивно осознать, что это такое, вспомним о системах, работаю¬ 
щих в режиме разделения времени. Предположим, периодически операционная 
система решает остановить работу одного процесса и запустить другой, потому что 
первый израсходовал отведенную для него часть рабочего времени центрального 
процессора в прошедшую секунду. 

Если процесс был приостановлен подобным образом, позже он должен быть 
запущен заново из того же состояния, в каком его остановили. Следовательно, всю 
информацию о процессе нужно где-либо явно сохранить на время его приостанов¬ 
ки. Например, процесс может иметь открытыми для чтения несколько файлов 
одновременно. Связанный с каждым файлом указатель дает текущую позицию 
(то есть номер байта или записи, которые будут прочитаны следующими). При 
временном прекращении процесса все указатели нужно сохранить так, чтобы ко¬ 
манда чтения, выполненная после возобновления процесса, прочла правильные 
данные. Во многих операционных системах вся информация о каждом процессе, 
дополнительная к содержимому его собственного адресного пространства, хранит¬ 
ся в таблице операционной системы. Эта таблица называется таблицей процес¬ 
сов и представляет собой массив (или связанный список) структур, по одной на 
каждый существующий в данный момент процесс. 

Таким образом, приостановленный процесс состоит из собственного адресного 
пространства, обычно называемого образом памяти (соге іша§е, соге в переводе 
означает «сердечник», в честь использовавшейся давным-давно памяти на магнит¬ 
ных сердечниках), и компонентов таблицы процесса, содержащей, помимо других 
величин, его регистры. 

Главными системными вызовами, управляющими процессами, являются вызо¬ 
вы, связанные с созданием и окончанием процессов. Рассмотрим типичный пример. 
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Глава 1. Введение 


Процесс, называемый интерпретатором команд или оболочкой (зЬеІІ), читает 
команды с терминала. Пользователь только что напечатал команду, содержащую 
запрос на компиляцию программы. Теперь оболочка должна создать новый про¬ 
цесс, который запустит компилятор. Когда процесс закончит компиляцию, он вы¬ 
полнит системный вызов, завершающий его собственную работу. 

Если процесс может создавать несколько других процессов (называющихся 
дочерними процессами), а эти процессы, в свою очередь, тоже могут создать дочер¬ 
ние процессы, перед нами предстает дерево процессов, изображенное на рис. 1.12. 
Связанные процессы — это те, которые объединены для выполнения некоторой 
задачи, и им нужно часто передавать данные от одного к другому и синхронизиро¬ 
вать свою деятельность. Такая связь называется межпроцессным взаимодействи¬ 
ем и будет обсуждена в деталях в главе 2. 



Рис. 1.12. Дерево процесса. Процесс А создал два дочерних процесса В и С. 

Процесс В создал три дочерних процесса 6, Е и Р 

Другие системные вызовы предназначаются для запросов о предоставлении 
дополнительной памяти (или освобождении не использующейся памяти), ожида¬ 
нии завершения дочерних процессов и наложении одной программы на другую. 

Время от времени необходимо передавать информацию работающему процес¬ 
су так, чтобы он не простаивал в ожидании получения этой информации. Напри¬ 
мер, процесс, связанный с другим процессом на удаленном компьютере, делает это, 
посылая сообщения по сети. Чтобы предотвратить возможность потери сообще¬ 
ния или ответа на него, отправитель может потребовать от собственной операци¬ 
онной системы уведомления, если по истечении определенного интервала ожида¬ 
ния не будет получено подтверждение о получении сообщения. В этом случае он 
сможет повторить отправку сообщения. После установки таймера программа про¬ 
должит выполнение другой работы. 

Если по истечении определенного количества секунд ответа нет, операционная 
система посылает процессу сигнал тревоги. Сигнал вызывает временную оста¬ 
новку работы процесса независимо от того, что процесс делает в данный момент; 
сохраняет его регистры в стеке и запускает специальную процедуру обработки 
сигнала (например, передающую повторно предположительно потерянное сооб¬ 
щение). После завершения обработки сигнала работающий процесс запускается 
заново в том состоянии, в котором он находился до сигнала. Сигналы являются 
программными аналогами аппаратных прерываний и могут быть сгенерированы 
по различным причинам, а не только из-за истечения какого-либо интервала вре¬ 
мени. Многие аппаратные прерывания (например, вызванные выполнением недо¬ 
пустимой команды или использованием неправильного адреса) также преобразу¬ 
ются в сигналы процессу, в котором произошла ошибка. 
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Каждому пользователю, которому разрешено пользоваться системой, системный 
администратор присваивает ІІГО (ІНег ГОепііГісаііоп — идентификатор пользова¬ 
теля). У каждого работающего процесса есть идентификатор пользователя, запус¬ 
тившего его. Дочерний процесс получает тот же самый 11Ш, что и его родитель. 
Пользователи могут становиться членами групп, каждая из которых имеет иден¬ 
тификатор группы (СЮ, Сгоир ГОепіШсаііоп). 

Пользователь с особым идентификатором ПГО, называемый в ІЖІХ «супер¬ 
пользователем» (зирегизег), имеет особые полномочия и может игнорировать 
множество правил защиты. В огромных системах только системный администра¬ 
тор знает пароль, необходимый для того, чтобы стать суперпользователем. Одна¬ 
ко множество обыкновенных пользователей (особенно студенты) тратят значи¬ 
тельное количество времени и труда на то, чтобы найти брешь в системе, которая 
позволит им стать суперпользователями без пароля. 

Мы изучим процессы, взаимодействие между ними и связанные с ними во¬ 
просы в главе 2. 

Взаимоблокировка 

Когда взаимодействуют два или более процессов, они могут попадать в патовые 
ситуации, из которых невозможно выйти без посторонней помощи. Такая ситуа¬ 
ция называется тупиком, тупиковой ситуацией или взаимоблокировкой. 

Тупиковую ситуацию легче всего представить с помощью примера из реально¬ 
го мира, с которым знаком каждый, — это пробки на дорогах. Обсудим ситуацию 
на рис. 1.13, а. Четыре автобуса приближаются к перекрестку. За каждым автобу¬ 
сом есть еще машины (они не показаны на рисунке). При определенном невезе¬ 
нии первые четыре автобуса прибудут на перекресток одновременно, что приве¬ 
дет к ситуации, показанной на рис. 1.13, 6. Все автобусы заблокировали друг друга, 
поскольку ни один автобус не может двигаться вперед. Каждый автобус блокиру¬ 
ет остальные. При этом они не могут двигаться назад, потому что за ними есть еще 
автобусы. И нет простого способа выпутаться из этой ситуации. 



Рис. 1.13. Потенциальная взаимоблокировка (а); фактическая взаимоблокировка (б) 
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Компьютерные процессы могут попадать в аналогичные ситуации, в которых 
они не могут продвигаться дальше. Представьте себе компьютер с накопителем на 
магнитной ленте и записывающим компакт-диски устройством (СЭ-гесогбег). 
Теперь представьте, что каждому из двух процессов нужно записать данные с лен¬ 
ты на компакт-диск. Процесс 1 запрашивает и получает в пользование устройство 
с лентой. Затем процесс 2 запрашивает и получает устройство для записи компакт- 
дисков. После этого процесс 1 запрашивает устройство для записи компакт-дис¬ 
ков и приостанавливается до тех пор, пока процесс 2 не освободит его. Наконец, 
процесс 2 запрашивает устройство с лентой и также останавливается на время, 
потому что магнитофон уже занят процессом 1. Перед нами типичный тупик, из 
которого нет выхода. Мы в деталях изучим тупиковые ситуации и посмотрим, что 
можно с ними делать в главе 3. 

Управление памятью 

В каждом компьютере есть оперативная память, используемая для хранения выпол¬ 
няющихся программ. В очень простых операционных системах в конкретный момент 
времени в памяти может находиться только одна программа. Для запуска второй 
программы сначала нужно удалить из памяти первую и загрузить на ее место вторую. 

Более изощренные системы позволяют одновременно находиться в памяти не¬ 
скольким программам. Для того чтобы они не мешали друг другу (и операцион¬ 
ной системе), необходим некий защитный механизм. Хотя этот механизм распо¬ 
лагается в аппаратуре, он управляется операционной системой. 

Вышеизложенная точка зрения имеет отношение к управлению оперативной 
памятью компьютера и к ее защите. Другой, но не менее важный, связанный с па¬ 
мятью вопрос — это управление адресным пространством процессов. Обычно под 
каждый процесс отводится некоторый набор адресов, которые он может исполь¬ 
зовать, чаще всего начинающийся с 0 и продолжающийся до некого максимума. 
В простейшем случае максимальная величина адресного пространства для процес¬ 
са меньше основной памяти. Тогда процесс может заполнить свое адресное про¬ 
странство, и памяти хватит на то, чтобы содержать его целиком. 

Однако на многих компьютерах адресация 32- или 64-разрядная, что дает для 
пространства адресов 2 32 и 2 е4 байтов соответственно. Что произойдет, если адрес¬ 
ное пространство процесса окажется больше, чем оперативная память компьюте¬ 
ра, и процесс захочет использовать его целиком? На первых компьютерах подоб¬ 
ным процессам просто не везло. В наши дни существует метод, называемый 
виртуальной памятью, при котором операционная система держит часть адресов 
в оперативной памяти, а часть на диске и меняет их местами при необходимости. 
Эта важная функция операционной системы, а также другие понятия, связанные 
с управлением памятью, будут рассмотрены в главе 4. 


Ввод-вывод данных 

Во всех компьютерах есть физическое устройство для получения входных данных 
и вывода информации. Посудите сами, что хорошего было бы в компьютере, если 
бы пользователи не могли сказать ему, что делать, и не могли получить результа- 
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ты после завершения выполненной работы? Существует много видов устройств 
ввода-вывода, например клавиатуры, мониторы, принтеры и т. д. Всеми ими долж¬ 
на управлять операционная система. 

Каждая операционная система имеет свою подсистему ввода-вывода для управ¬ 
ления устройствами ввода-вывода. Некоторые из программ ввода-вывода являют¬ 
ся независимыми от устройств, то есть их можно применить ко многим или ко всем 
устройствам ввода-вывода. Другая часть программного обеспечения ввода-выво¬ 
да, в которую входят драйверы устройств, предназначена для определенных уст¬ 
ройств ввода-вывода. В главе 5 мы рассмотрим программное обеспечение ввода- 
вывода данных. 

Файлы 

Файловая система — это еще одно ключевое понятие, поддерживаемое виртуаль¬ 
но всеми операционными системами. Как было замечено ранее, основной функ¬ 
цией операционной системы является скрытие особенностей дисков и других 
устройств ввода-вывода и предоставление пользователю понятной и удобной аб¬ 
страктной модели независимых от устройств файлов. Системные вызовы очевид¬ 
но необходимы для создания, удаления, чтения или записи файлов. Перед тем как 
прочитать файл, его нужно разместить на диске и открыть, а после прочтения его 
нужно закрыть. Все эти функции осуществляют системные вызовы. 

Предоставляя место для хранения файлов, операционные системы используют 
понятие каталога (сіігесіогу) как способ объединения файлов в группы. Например, 
студент может иметь по одному каталогу для каждого изучаемого им курса (для 
программ, необходимых в рамках этого курса), каталог для электронной почты, 
и еще один — для своей домашней \ѵеЬ-страницы. Для создания и удаления ката¬ 
логов также необходимы системные вызовы. Они же обеспечивают перемещение 
существующего файла в каталог и удаление файла из каталога. Содержимое ка¬ 
талогов могут составлять файлы или другие каталоги. Эта модель создает струк¬ 
туру — файловую систему, — как показано на рис. 1.14. 

Иерархии процессов и файлов организованы в виде деревьев, но на этом сход¬ 
ство заканчивается. Иерархия процессов обычно не очень глубока (в ней редко 
бывает больше трех уровней), тогда как файловая структура достаточно часто 
имеет четыре, пять или даже больше уровней в глубину. Иерархия процессов обыч¬ 
но живет очень недолго, как правило, несколько минут, иерархия каталогов может 
существовать годами. Принадлежность и защита также различны для процессов и 
файлов. Обычно только родительский процесс может управлять или даже просто 
иметь доступ к дочернему процессу, однако практически всегда существует меха¬ 
низм, позволяющий читать файлы и каталоги не только владельцу файла, а более 
широкой группе пользователей. 

Каждый файл в иерархии каталогов можно определить, задав его имя пути, на¬ 
зываемое также полным именем файла. Путь начинается из вершины структуры 
каталогов, называемой корневым каталогом. Такое абсолютное имя пути состо¬ 
ит из списка каталогов, которые нужно пройти от корневого каталога к файлу, 
с разделением отдельных компонентов косой чертой. На рис. 1.14 путь к файлу 
С5101 выглядит как/ РасиІіу/Рго/.Вготоп/Соигзез/СЗІОІ . Первая косая черта гово- 
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рит о том, что этот путь — абсолютный, то есть начинается от корневого каталога. 
В М5-005 и \Ѵіпсіо\ѵ5 для разделения компонентов вместо символа косой черты 
используется обратная косая черта (\). Тогда этот путь будет выглядеть так: 
\Расику\Рго/.Вгошт \Соигзез\С5101. В нашей книге для записи пути мы в основном 
будем использовать соглашения ІЖІХ. 


Корневой каталог 



Рис. 1.14. Файловая система факультета университета 

В каждый момент времени у каждого процесса есть текущий рабочий каталог, 
в котором ищутся пути файлов, не начинающиеся с косой черты. Например, если 
на рис. 1.14 /ГасиІІу/Рт/.Вгоаіп является рабочим каталогом, то использование 
пути Соигзез/С5101 даст тот же самый файл, что и абсолютный путь, написанный 
выше. Процессы могут изменять свой рабочий каталог, используя системные вызовы. 

Перед тем как прочесть или записать файл, его нужно открыть, в это же время 
проверяется разрешение доступа. Если доступ разрешен, система возвращает не¬ 
большое целое число, называемое дескриптором файла и используемое в после¬ 
дующих операциях. Если доступ запрещен, то возвращается код ошибки. 

Другое важное понятие в ІЖІХ — это установленная (смонтированная) фай¬ 
ловая система. Почти все персональные компьютеры имеют один или два диско¬ 
вода для гибких дисков, куда можно вставить и откуда можно вынуть диск. Чтобы 
предоставить возможность общения со сменными носителями (включая компакт- 
диски), ІЖІХ позволяет присоединять файловую систему сменного диска к глав¬ 
ному дереву. Рассмотрим ситуацию на рис. 1.15, а. Перед вызовом системной про¬ 
цедуры тоипТ корневая файловая система на жестком диске и вторая файловая 
система на гибком диске существуют раздельно и никак не связаны между собой. 
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Корень Гибкий диск 



Рис. 1.15. Перед установкой файлы на диске 0 недоступны (а); после монтирования 
они становятся частью общей файловой структуры (б) 


Однако файлы на гибком диске нельзя использовать, потому что для них невоз¬ 
можно определить путь. ІЖІХ не позволяет присоединять к началу пути название 
диска или его номер, так как это привело бы к жесткой зависимости от устройств, 
которой операционная система должна избегать. Вместо этого системный вызов 
тоигФ позволяет присоединять файловую систему на гибком диске к корневой фай¬ 
ловой системе в том месте, где этого захочет программа. На рис. 1.15, б файловая 
система гибкого диска была установлена в каталог Ь , таким образом, обеспечен 
доступ к файлам по путям /Ь/х/и /Ь/у. Если каталог Ь содержал какие-либо фай¬ 
лы, они будут недоступны, пока смонтирован гибкий диск, так как теперь /Ь ссыла¬ 
ется на корневой каталог гибкого диска. (Невозможность доступа к этим файлам 
не так страшна, как кажется с первого взгляда: файловые системы почти всегда 
устанавливаются в пустые каталоги.) Если система содержит несколько жестких 
дисков, они все могут быть встроены в одно дерево таким же образом. 

Еще одно важное понятие в ІІШХ — это специальный файл. Специальные фай¬ 
лы служат для того, чтобы устройства ввода-вывода выглядели как файлы. При 
этом можно прочесть информацию из специальных файлов или записать ее туда 
с помощью тех же самых системных вызовов, что используются для чтения и за¬ 
писи файлов. Существует два вида специальных файлов: блочные специальные 
файлы и символьные специальные файлы. Блочные специальные файлы исполь¬ 
зуются для моделирования устройств, состоящих из набора произвольно адресуе¬ 
мых блоков, таких как диски. Открывая блочный специальный файл и читая, ска¬ 
жем, блок 4, программа может напрямую получить доступ к четвертому блоку на 
устройстве, без обращения к содержащейся на нем файловой системе. Таким же 
образом символьные специальные файлы используются для моделирования прин¬ 
теров, модемов и других устройств, которые принимают или выдают поток симво¬ 
лов. По соглашению специальные файлы хранятся в каталоге /д.еѵ. Например, 
/сіеѵ/ір может быть строковым принтером. 

И последнее понятие, которое мы обсудим во введении, — это каналы (ріре), 
имеющие отношение и к процессам и к файлам. Канал (также иногда называемый 
трубой) представляет собой псевдофайл, который можно использовать для связи 
двух процессов, как показано на рис. 1.16. Если процессы АиВ захотят пообщать¬ 
ся с помощью канала, они должны установить его заранее. Когда процесс А хочет 
отправить данные процессу В, он пишет их в канал, как если бы это был выходной 
файл. Процесс В может прочесть данные, читая их из канала, как если бы он был 
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файлом с входными данными. Таким образом, соединение между процессами в ІШІХ 
выглядит очень похожим на обычное чтение и запись файлов. Более того, только 
сделав специальный системный вызов, процесс может обнаружить, что выходной 
файл, в который он пишет данные, не реальный файл, а канал. Файловые системы 
очень важны. Мы расскажем о них значительно больше в главе 6, а также в гла¬ 
вах 10 и 11. 


Процесс Процесс 

/" Канал /'’ 

А ь = — М В 


Рис. 1.16. Два процесса, соединенные каналом 

Безопасность 

Компьютеры содержат большое количество информации, конфиденциальность 
которой пользователи зачастую хотят сохранить: электронную почту, бизнес-пла¬ 
ны и многое другое. В задачу операционной системы входит управление систе¬ 
мой защиты подобных файлов, так чтобы они, например, были доступны только 
пользователям, имеющим на это права. 

В качестве простейшего примера, дающего представление о том, как работает 
система безопасности, рассмотрим систему БПчНХ. В ІЖІХ для защиты файлов им 
присваивается 9-битовый двоичный код. Этот код защиты состоит из трех полей 
по три бита; одно для владельца, второе для других членов группы владельца 
(пользователи разделяются на группы системным администратором) и третье — 
для всех остальных. В каждом поле есть бит, определяющий доступ для чтения, 
бит, определяющий доступ для записи, и бит, разрешающий выполнение. Эти три 
бита называются пѵх-битами (геасі, ѵѵгіСе, схесШс). Например, код защиты тхг-х—х 
означает, что владелец файла может читать, писать или выполнять файл, другие 
члены группы могут читать или выполнять файл (но не писать в него), а осталь¬ 
ные могут только выполнять файл (но не читать или писать). Для каталогах озна¬ 
чает разрешение на поиск. Дефис означает, что соответствующее разрешение от¬ 
сутствует. 

Кроме защиты файлов, существует еще множество других вопросов безопас¬ 
ности: защита системы от нежелательных гостей, людей, и не только (вирусов). 
Мы обсудим различные вопросы, связанные с безопасностью, в главе 9. 


Оболочка 

Операционная система представляет собой программу, выполняющую системные 
вызовы. Редакторы, компиляторы, ассемблеры, компоновщики и командные интер¬ 
претаторы не являются частью операционной системы, несмотря на их большую 
важность и полезность. Поскольку есть риск запутаться в этих вещах, в данном 
разделе мы кратко рассмотрим только командный интерпретатор ІШІХ, называе¬ 
мый оболочкой (ьЬеІІ). Хотя она не входит в операционную систему, но во всю 
пользуется многими функциями операционной системы и поэтому является хоро¬ 
шим примером того, как могут применяться системные вызовы. Кроме этого, 
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оболочка предоставляет основной интерфейс между пользователем, сидящим за 
своим терминалом, и операционной системой, если, конечно, пользователь не ис¬ 
пользует графический интерфейс. Существует множество оболочек, например зк, 
сзк, кзк и Ъазк. Все они поддерживают описанные ниже функции, поскольку про¬ 
изошли от первоначальной оболочки (х/г). 

Когда какой-либо пользователь входит в систему, запускается оболочка. Стандарт¬ 
ным входным и выходным устройством для оболочки является терминал (мони¬ 
тор с клавиатурой). Оболочка начинает работу с печати приглашения (ргошрі) — 
знака доллара, говорящего пользователю, что оболочка ожидает ввода команды. 
Если теперь пользователь напечатает, например, 

сМе 

оболочка создаст дочерний процесс и запустит программу с іаіе . Пока дочерний про¬ 
цесс работает, оболочка ожидает его завершения. После завершения дочернего про¬ 
цесса оболочка опять печатает приглашение и пытается прочесть следующую вход¬ 
ную строку. Пользователь может перенаправить стандартный вывод данных в файл: 

сіаіе >іі1е 

Таким же образом можно переопределить устройство, с которого читаются 
входные данные, как показано ниже: 

5оП <ТПе1 >іі 1е2 

Эта команда предписывает программе сортировки считать данные из файла 1 
и вывести результат в файл 2. 

Выходные данные одной программы можно использовать в качестве входных 
данных для другой, соединив их каналом. Так, команда 

саі Тііеі Іі1е2 ііІеЗ | зогі >/сІеѵ/1р 

предписывает программе саі объединить (сопсоіепаіе) три файла и послать выходные 
данные программе зогі, которая расставит все строки в алфавитном порядке. Резуль¬ 
тат работы зогі перенаправляется в файл /сіеѵ/ір, обычно обозначающий принтер. 

Если пользователь наберет знак & после команды, оболочка не будет ждать 
окончания ее выполнения. В этом случае она немедленно напишет новое пригла¬ 
шение. То есть в результате команды 

саі іііеі Іі1е2 ііІеЗ | богі >/сІеѵ/1р & 

сортировка запустится как фоновое задание, разрешая пользователю продолжать 
нормальную работу во время выполнения сортировки. Оболочка имеет множество 
других интересных особенностей, для обсуждения которых у нас здесь, к сожале¬ 
нию, недостаточно места. Но большинство книг по ІШІХ описывают оболочки 
довольно подробно [179, 185, 232, 245, 278]. 


Повторное использование идей 

Кибернетика (наука о компьютерах), как и множество других областей знания, 
находится в сильной зависимости от технологий. Причиной отсутствия автомо¬ 
билей у древних римлян являлось вовсе не то, что они очень любили ходить пеш- 
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ком. Машин не было потому, что римляне просто не знали, как их сконструиро¬ 
вать. И персональные компьютеры существуют не потому, что миллионы людей 
долгое время хотели иметь свой собственный компьютер, но сдерживали это же¬ 
лание, а потому, что теперь можно относительно дешево их производить. Мы час¬ 
то забываем, как сильно влияет технология на наше видение систем, и действи¬ 
тельно полезно поразмышлять об этом время от времени. 

Часто случается, что из-за изменений в технологии некоторые идеи устарева¬ 
ют. Но другие изменения в технологии могут вновь оживить их. Такое случается 
главным образом тогда, когда происходящие изменения имеют отношение к от¬ 
носительной производительности различных частей системы. Например, когда 
скорость центрального процессора начинает намного превышать быстродействие 
памяти, кэш становится очень важной деталью, увеличивающей скорость «медлен¬ 
ной» памяти. Если новые технологии в области памяти когда-нибудь создадут 
память намного более быструю, чем процессор, кэш станет не нужным. Но если 
затем процессоры опять станут более быстрыми, чем память, кэш появится снова. 
В биологии вымирание происходит навсегда, но в кибернетике иногда это бывает 
только на несколько лет. 

Из-за такого непостоянства в данной книге время от времени мы будем рассмат¬ 
ривать «устаревшие» концепции, то есть идеи, не оптимальные для современных 
технологий. Но изменения в технологии могут вернуть к жизни некоторые из так 
называемых «устаревших понятий». По этой причине важно понять, почему кон¬ 
цепция является устаревшей и какие изменения в окружающей обстановке могут 
оживить ее. 

Чтобы пояснить нашу точку зрения, рассмотрим несколько примеров. Ранние 
компьютеры имели вмонтированный в аппаратуру набор команд. Затем появилось 
микропрограммирование, при котором интерпретатор выполнял команды про¬ 
граммно. Аппаратное выполнение устарело. После этого были созданы ЕІЗС- 
компьютеры, и микропрограммирование (то есть интерпретируемое выполнение) 
тоже стало устаревшим понятием, поскольку исполнение команд напрямую ока¬ 
залось быстрее. Теперь мы наблюдаем возрождение интерпретации в форме ап¬ 
плетов ^ѵа, которые передаются по Интернету и интерпретируются по прибытии. 
Здесь скорость выполнения не играет решающей роли, поскольку задержки в сети 
настолько велики, что основное время тратится на них. Но все это тоже однажды 
может измениться. 

Ранние компьютерные системы размещали файлы на диске, располагая их в со¬ 
седних секторах, один за другим. Хотя эта схема осуществляется очень просто, она 
не является гибкой, поскольку если файл увеличился в размере, уже не будет мес¬ 
та для его хранения. Концепция непрерывного размещения файлов была отверг¬ 
нута и стала устаревшей. До тех пор, пока не появились компакт-диски. Для них 
не существует проблемы роста файлов. Внезапно простота непрерывного разме¬ 
щения файлов оказалась гениальной идеей, и на ней сейчас базируются файловые 
системы компакт-дисков. 

И наконец, рассмотрим динамическое связывание. Система МШДГІС5 проек¬ 
тировалась так, чтобы она могла функционировать днем и ночью без остановок. 
Чтобы программно исправлять системные ошибки, необходимо было найти спо¬ 
соб, позволяющий заменять библиотечные процедуры во время их использования. 
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Для этой цели придумали понятие динамического связывания. После того как 
система М1ЛЛ1С5 отжила свое, это понятие было на время забыто. Но его открыли 
заново, когда современным операционным системам понадобился способ, позволя¬ 
ющий нескольким программам делить между собой одну библиотечную процеду¬ 
ру, не создавая для себя собственной копии (потому что графические библиотеки 
выросли до невероятных размеров). Сейчас большинство систем снова поддержи¬ 
вает некоторую форму динамического связывания. Список можно еще продол¬ 
жить, но мораль описанных выше примеров такова: идея, которая сегодня являет¬ 
ся устаревшей, завтра может стать гвоздем сезона. 

Не только технологии влияют на системы и программное обеспечение. Важную 
роль играет и экономика. В 60-х и 70-х годах большинство терминалов было 
механически печатающими устройствами или алфавитно-цифровыми дисплеями 
с электронно-лучевыми трубками, предназначенным для вывода 25 х 80 символов, 
а не графическими терминалами с растровым отображением. Этот выбор был обус¬ 
ловлен не технологиями. Растровые графические терминалы использовались еще 
до 1960 года. Но они стоили несколько десятков тысяч долларов каждый. Только 
после сильного падения цен люди (а не только военные) смоли задуматься о пре¬ 
доставлении каждому пользователю собственного терминала. 


Системные вызовы 

Интерфейс между операционной системой и программами пользователя опреде¬ 
ляется набором системных вызовов, предоставляемых операционной системой. 
Чтобы на самом деле понять, что же делает, операционная система, мы должны 
подробно рассмотреть этот интерфейс. Системные вызовы, доступные в интерфей¬ 
се, меняются от одной операционной системы к другой (хотя лежащая в их основе 
концепция практически одинакова). 

Теперь мы столкнулись с проблемой выбора между (1) неопределенными обоб¬ 
щениями («операционные системы имеют системные вызовы для чтения файлов») 
и (2) какой-либо конкретной системой («в ІЖІХ существует системный вызов для 
чтения с тремя параметрами: один для задания файла, второй — для того, чтобы 
указать, куда нужно поместить прочитанные данные, третий задает количество 
байтов, которое нужно прочитать»). 

Мы выбрали второй подход. При этом способе нужно проделать больше ра¬ 
боты, но он обеспечивает лучшее понимание того, что в реальности происходит 
в операционной системе. Несмотря на то что это обсуждение затрагивает конк¬ 
ретно стандарт РОЗІХ (международный стандарт 9945-1), а, следовательно, так¬ 
же и операционные системы ІЖІХ, Зузіет V, ВЗП, Ілпих, МІШХ и т. д., у боль¬ 
шинства других современных операционных систем есть системные вызовы, 
выполняющие те же самые функции, хотя детали могут быть различны. Так как 
фактический механизм обращения к системным функциям является в высокой 
степени машинно-зависимым и часто должен реализовываться на ассемблере, 
существуют библиотеки процедур, делающие возможным обращение к системным 
процедурам из программ на С и других языках с тем же успехом. 
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Очень полезно всегда помнить следующее. Любой компьютер с одним про¬ 
цессором в каждый конкретный момент времени может выполнить только одну 
команду. Если процесс выполняет программу пользователя в пользовательском ре¬ 
жиме и нуждается в системной службе, например чтении данных из файла, он дол¬ 
жен выполнить прерывание или команду системного вызова для передачи управ¬ 
ления операционной системе. Затем операционная система по параметрам вызова 
определяет, что требуется вызывающему процессу. После этого она обрабатывает 
системный вызов и возвращает управление команде, следующей за системным 
вызовом. В известном смысле выполнение системного вызова похоже на осуще¬ 
ствление вызова процедуры, только первый проникает в ядро, а второй этого не 
делает. 

Для того чтобы прояснить механизм системных вызовов, кратко рассмотрим 
системный вызов геасі. Как упоминалось выше, у него есть три параметра: первый 
служит для задания файла, второй указывает на буфер, третий задает количество 
байтов, которое нужно прочитать. Как практически все системные вызовы, он за¬ 
пускается из программы на С с помощью вызова библиотечной процедуры с тем 
же именем, что и системный вызов: геасі. Вызов из программы на С может выгля¬ 
деть так: 

соипі = геасКГсІ. ЬиГГег. пЬуіез): 

Системный вызов (и библиотечная процедура) возвращает количество дей¬ 
ствительно прочитанных байтов в переменной соипі. Обычно эта величина совпа¬ 
дает с параметром пЬуіез, но может быть меньше, если, например, в процессе чте¬ 
ния процедуре встретился конец файла. 

Если системный вызов не может быть выполнен или из-за неправильных пара¬ 
метров или из-за дисковой ошибки, значение счетчика соипі устанавливается рав¬ 
ным -1, а номер ошибки помещается в глобальную переменную егто. Программы 
всегда должны проверять результат системного вызова, чтобы отслеживать появ¬ 
ление ошибки. 

Системные вызовы выполняются за серию шагов. Вернемся к упоминавшему¬ 
ся выше примеру вызова геасі для того, чтобы разъяснить этот момент. Сначала 
при подготовке к вызову библиотечной процедуры геаф которая фактически 
осуществляет системный вызов геасі, вызывающая программа помещает парамет¬ 
ры в стек, как показано в шагах 1-3 на рис. 1.17. Компиляторы С и С++ помещают 
параметры в стек в обратном порядке, так исторически сложилось (чтобы первым 
был параметр для ргіпі /, то есть строка формата оказалась на вершине стека). Пер¬ 
вый и третий параметры передаются по значению, а второй параметр передается 
по ссылке, то есть передается адрес буфера (на то, что это ссылка, указывает сим¬ 
вол &), а не его содержимое. Затем следует собственно вызов библиотечной про¬ 
цедуры (шаг 4). Эта команда процессора представляет собой обычную команду 
вызова процедуры и применяется для вызова любых процедур. 

Библиотечная процедура, возможно, написанная на ассемблере, обычно по¬ 
мещает номер системного вызова туда, где его ожидает операционная система, 
например в регистр (шаг 5). Затем она выполняет команду ТКАР (эмулированное 
прерывание) для переключения из пользовательского режима в режим ядра и на¬ 
чинает выполнение с фиксированного адреса внутри ядра (шаг б). Запускаемая 
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программа ядра проверяет номер системного вызова и затем отправляет его нуж¬ 
ному обработчику, как правило, используя таблицу указателей на обработчики 
системных вызовов, индексированную по номерам вызовов (шаг 7). В этом месте 
начинает функционировать обработчик системных вызовов (шаг 5). Как только он 
завершает свою работу, управление может возвращаться в пространство пользо¬ 
вателя к библиотечной процедуре, к команде, следующей за командой ТКАР (шаг 9). 
Эта процедура в свою очередь передает управление программе пользователя обыч¬ 
ным способом, которым производится возврат из вызванной процедуры (шаг 10). 

Чтобы закончить работу, программа пользователя должна очистить стек, как 
это делается и после каждого вызова процедуры (шаг 11). Учитывая, что стек рас¬ 
тет вниз, последняя команда увеличивает указатель стека ровно настолько, на¬ 
сколько нужно для удаления параметров, помещенных в стек перед запросом геасі. 
Теперь программа может продолжать свою работу. 


Адреса 

ОхРРРРРРРР 


Пространство 7 
пользователя ] 


Ядро 

(операционная 

система) 


О 



Библиотечная 
процедура геасі 


Программа 
пользователя, 
вызывающая геасі 


Рис. 1.17. 11 этапов выполнения системного вызова геасЦІсі, ЬиНег, пЬуІез) 


На шаге 9 мы использовали выражение «может возвращаться в пространство 
пользователя к библиотечной процедуре...» не просто так. Системный вызов мо¬ 
жет блокировать вызвавшую его процедуру, препятствуя продолжению ее рабо¬ 
ты. Например, если она пытается прочесть что-то с клавиатуры, а там еще ничего 
не набрано, процедура должна быть блокирована. В этом случае операционная 
система ищет процесс, который может быть запущен следующим. Позже, когда 
нужное устройство станет доступно, система вспомнит о блокированном процессе 
и шаги 9-11 будут выполнены. 
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В следующих разделах мы рассмотрим некоторые из наиболее часто применяю¬ 
щихся системных вызовов стандарта Р05ІХ или, точнее, библиотечных процедур, 
которые выполняют эти вызовы. В Р05ІХ существует более 100 процедурных 
вызовов. Часть наиболее важных процедурных вызовов представлена в табл. 1.1, 
где они для удобства распределены в четыре группы. Далее мы кратко опишем каж¬ 
дый вызов и его действие. Службы, предоставляемые этими вызовами, в значи¬ 
тельной степени определяют действия операционной системы, так как управле¬ 
ние ресурсами на персональном компьютере минимально (по крайней мере, по 
сравнению с большими машинами, на которых работают несколько пользовате¬ 
лей). К этим службам относятся такие функции, как создание и завершение про¬ 
цессов, создание, удаление, чтение и запись файлов, управление каталогами, вы¬ 
полнение ввода и вывода. 


Таблица 1.1. Некоторые из основных системных вызовов Р05ІХ 


Вызов 

Описание 

Управление процессами 

РісІ=Тогк() 1 

Ріб=ѵѵаі1рісі(рісі, &зІаІІос, орііопз) 
з=ехесѵе(пате, агдѵ, епѵігопр) 
Ехіі(зіаіиз) 

Создает дочерний процесс, идентичный родительскому 
Ожидает завершения дочернего процесса 

Перемещает образ памяти процесса 

Завершает выполнение процесса и возвращает статус 

Управление файлами 

М=ореп(1ІІе, Ноѵѵ, ...) 
з=сІозе(М) 

п=геасі(Щ, ЬиНег, пЬуІез) 
п=ѵѵгіІе(М, ЬиНег, пЬуІез) 
РозіІіоп=Ізеек(Щ, оЦзеІ, ѵѵбепсе) 
5=зІаІ(пате, &Ьи1) 

Открывает файл для чтения, записи или того и другого 
Закрывает открытый файл 

Читает данные из файла в буфер 

Пишет данные из буфера в файл 

Передвигает указатель файла 

Получает информацию о состоянии файла 

Управление каталогами и файловой системой 

з=тксІіг(пате, тобе) 
з=гтсііг(пате) 
з=1іпк(пате1, пате2) 

з=ипІіпк(пате) 
з=тоипІ(зресіаІ, пате, Над) 
з=итоипІ(зресіаІ) 

Создает новый каталог 

Удаляет пустой каталог 

Создает новый элемент с именем пате2, указывающий 
на патеі 

Удаляет элемент каталога 

Монтирует файловую систему 

Демонтирует файловую систему 

Разные 

з=сМіг(сіітате) 
з=сбтоб(пате, тобе) 
з=кіІІ(ріб, зідпаі) 
Зесопбз=Ііте(&зесопбз) 

Изменяет рабочий каталог 

Изменяет биты защиты файла 

Посылает сигнал процессу 

Получает время, прошедшее с 1 января 1970 года 


1 Возвращаемая величина з равна -1, если произошла ошибка. Возвращаемые коды выглядят так: рісі 
выдает идентификатор процесса,/# — описатель файла, п — количество байтов, розіііоп — смещение 
в файле изесопсіз — прошедшее время. Параметры описываются дальше в тексте. 














Системные вызовы 


73 


Особое внимание следует обратить на то, что преобразование вызовов проце¬ 
дур Р05ІХ в системные вызовы не является взаимно однозначным. Стандарт 
Р05ІХ определяет ряд процедур, которые должны поддерживать совместимые 
системы, но он не указывает, являются ли они системными вызовами, библиотеч¬ 
ными вызовами или чем-нибудь еще. Если процедуру можно выполнить без сис¬ 
темного вызова (то есть без переключения в режим работы ядра), то обычно она 
работает в пространстве пользователя, потому что так быстрее. Однако большин¬ 
ство процедур Р05ІХ выполняет системные вызовы, обычно с одной процедурой, 
преобразующейся напрямую в системный вызов. В некоторых случаях, особенно 
когда требуемые процедуры являются всего лишь разновидностями друг друга, 
один системный вызов обрабатывает сразу несколько библиотечных вызовов. 

Системные вызовы для управления процессами 

Первая группа в табл. 1.1 управляет процессами. Начнем рассмотрение с вызова 
ІЪгк. Системный вызов ІЪгк (разветвление) является единственным способом со¬ 
здания нового процесса в ІЖІХ. Он создает точную копию исходного процесса, 
включая дескрипторы файла, регистры и т. п. После вызова Ітзгк исходный процесс 
и его копия (родительский и дочерний) развиваются по отдельности друг от друга. 
Все переменные имеют одинаковые величины во время вызова ‘Гогк, но как только 
родительские данные скопированы для создания дочернего процесса, последу¬ 
ющие изменения в одном из них уже не влияют на другой. (Текст программы, ко¬ 
торый не изменяется, распределяется между родительским и дочерним процес¬ 
сами). Вызов йзгк возвращает величину, равную нулю в дочернем процессе и равную 
идентификатору дочернего процесса или РГО в родительском. Используя возвра¬ 
щенный РШ, два процесса могут различить, какой из них родительский, а какой — 
дочерний. 

В большинстве случаев после вызова Рэгк дочернему процессу необходимо вы¬ 
полнить программный код, отличный от предназначенного для родительского про¬ 
цесса. Рассмотрим пример оболочки. Она читает команды с терминала, запускает 
дочерний процесс, ждет, пока дочерний процесс выполнит команду, и читает сле¬ 
дующую команду после завершения работы дочернего процесса. Ожидая, пока 
дочерний процесс закончит работу, родительский процесс выполняет системный 
вызов маіѣрісі, который ожидает завершения дочернего процесса (или всех дочер¬ 
них процессов, если их на данный момент несколько). МаіѣрісІ может ждать окон¬ 
чания какого-либо определенного дочернего процесса или любого дочернего про¬ 
цесса, для этого нужно задать первый параметр вызова равным -1. Когда маіірісі 
выполнен, указатель, задаваемый вторым параметром БЪаОос, будет установлен 
на статус завершения дочернего процесса (нормальное или аварийное завершение 
и выходное значение). Третий параметр определяет различные необязательные 
настройки. 

Теперь рассмотрим, как вызов Ітзгк используется оболочкой. Когда печатается 
команда, оболочка создает дочерний процесс, который должен выполнить коман¬ 
ду пользователя. Он делает это с помощью системного вызова ехесѵе, заменяюще¬ 
го весь его образ памяти файлом, названным в первом параметре. (Фактически 
самим системным вызовом является ехес, но несколько различных библиотечных 
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процедур вызывают его с разными параметрами и незначительно отличающимися 
именами. Мы здесь воспользуемся ими как системными вызовами.) Весьма упро¬ 
щенная оболочка, иллюстрирующая использование команд Гогк, иаіірісі и ехесѵе 
показана в листинге 1.1. 


Листинг 1.1. Усеченная оболочка 1 

#сІе-Гіпе ™е 1 
ѵѵИіІе (ТКІЮ { 

Гуре_рготрГ( ); 

геасі сотшапсКсотшапсі, рагатеГегз); 

И (?огк( ) !- 0) { 

/* текст родительского процесса */ 
ѵѵаіТрісК-І. &5ГаГи5. 0): 

} е1$е { 

/* текст дочернего процесса */ 
ехесѵе (соттагк), рагатеГегз. 0); 

} 

} 


/* вечный цикл */ 

/* печать приглашения на экране */ 

/* читать входные данные с терминала */ 
/♦запускает дочерний процесс */ 

/* ждать окончания дочернего процесса */ 


/* выполнение соттапр */ 


В самом общем случае у команды ехесѵе есть три параметра: имя файла, кото¬ 
рый будет выполняться, указатель на массив аргументов и указатель на массив 
переменных окружения. Эти параметры мы кратко обсудим в дальнейшем. Раз¬ 
личные библиотечные программы, включая ехесі, ехесѵ, ехесіе и ехесѵе, разрешают 
пропускать параметры или определять их другими способами. В книге мы восполь¬ 
зуемся названием ехес для того, чтобы представить системный вызов, вызываемый 
всеми этими процедурами. 

Рассмотрим следующую команду: 

ср Тліеі Гі1е2 


которая используется для копирования файла /ііеі в файл /Ііе2. После создания 
оболочкой дочернего процесса последний находит и исполняет файл ср и переда¬ 
ет ему имена исходного и целевого файлов. 

Основной модуль программы ср (как и большинство других головных программ 
на С) содержит определение: 


гпаі п(агдс. агдѵ, епѵр) 


в котором в параметр аще входит количество записей в командной строке, вклю¬ 
чая имя программы. Например, для строки вверху аще равен 3. 

Второй параметр аг§ѵ является указателем на массив указателей. Элемент і 
массива указывает на г-ю запись в командной строке. В нашем примере ащѵ[ 0] дол¬ 
жен указывать на слово «ср», аащѵ\[] и аг§ѵ[ 2] — на слова «Шеі» и «Ше2» соответ¬ 
ственно. 

Третий параметр функции таіп, епѵр, является указателем на массив строковых 
переменных окружения вида имя=величина, которые используются для передачи 
программе такой информации, как тип терминала или имя домашнего каталога. 
В листинге 1.1 третий параметр равен нулю, поскольку ничего не передается дочер¬ 
нему процессу. 


1 На протяжении всей книги значение константы ТКУЕ предполагается равным 1. — Примеч. авгп. 
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Если команда ехес кажется сложной, не огорчайтесь, потому что это один из 
наиболее сложных системных вызовов в Р05ІХ. Все остальные намного проще. 
В качестве еще одного примера рассмотрим ехіѣ, процессы должны использовать 
его при завершении работы. У него есть всего один параметр, статус выхода, изме¬ 
няющийся от 0 до 255. Он возвращается родительскому процессу через параметр 
зіаііос в системном вызове маИрісІ. 

В ІЖІХ под процессы отводится часть памяти, которая, в свою очередь, делится 
на три сегмента: текстовый (то есть код программы), сегмент данных (перемен¬ 
ные) и сегмент стека. Сегмент данных растет снизу вверх, а стек увеличивается 
сверху вниз, как показано на рис 1.18. Между ними существует часть неиспользо¬ 
ванного адресного пространства. Стек автоматически занимает такую часть этого 
участка памяти, какую необходимо, но расширение сегмента данных выполняется 
явным образом. Для этого используется специальный системный вызов Ьгк, зада¬ 
ющий новый адрес для границы сегмента данных. Однако этот вызов не опреде¬ 
лен стандартами Р05ІХ, так как программистам для динамического распределе¬ 
ния памяти рекомендуется использовать библиотечную процедуру таііос. Было 
решено, что низкоуровневую реализацию процедуры таііос не следует стандарти¬ 
зировать, потому что мало кто вызывает ее напрямую. 

Адрес 



Рис. 1.18. Под процессы отводится три сегмента: текст, данные и стек 

Системные вызовы для управления файлами 

Многие системные вызовы имеют отношение к файловой системе. В этом разделе мы 
рассмотрим вызовы, работающие с отдельными файлами, а в следующем разделе 
обратимся к тем, которые оперируют каталогами или файловой системой в целом. 

Чтобы прочитать или записать файл, его сначала нужно открыть при помощи 
вызова ореп. Для этого вызова указывается имя открываемого файла (задается 
или абсолютный путь файла, или ссылка на рабочий каталог) и код 0_КООЫЬУ, 
0_\ѴК0ЫЬУ или 0_КО\ѴК, означающий, что файл открывается для чтения, запи¬ 
си или и того и другого. Для создания нового файла используется код О _СКЕАТ. 
Возвращаемый дескриптор файла затем можно употребить при чтении или запи¬ 
си. Потом файл закрывается с помощью вызова сіозе, который делает дескриптор 
файла доступным при следующем открытии (ореп). 

Наиболее часто используемыми вызовами, без сомнения, являются геасі и ипѣе. 
Вызов геасі мы уже обсуждали, ѵ/гііе имеет те же самые параметры. 

. Несмотря на то что большинство программ читает и записывает файлы с по¬ 
мощью последовательного доступа, некоторым прикладным программам необхо- 




76 


Глава 1. Введение 


дима возможность доступа к любой, случайно выбранной части файла. Связанный 
с каждым файлом указатель содержит текущую позицию в файле. Когда чтение 
(запись) осуществляется последовательно, он обычно указывает на байт, который 
должен быть прочитан (записан) следующим. Вызов Ізеек может изменить значе¬ 
ние позиции указателя, так что следующий вызов геай или мгіѣе начнет операцию 
где-либо в другой части файла. 

У вызова 1 зеек есть три параметра: первый — это идентификатор файла, вто¬ 
рой — позиция в файле, а третий говорит, является ли второй параметр позицией 
в файле относительно начала файла (абсолютная позиция), относительно текущей 
позиции или относительно конца файла. Вызов 1 Беек возвращает абсолютную по¬ 
зицию в файле после изменения указателя. 

Для каждого файла ІШІХ хранит следующие данные: тип файла (обычный, 
специальный, каталог и т. д.), размер, время последнего изменения и другую ин¬ 
формацию. Программа может запросить эту информацию через системный вызов 
Бѣгѣ. Его первый параметр определяет требуемый файл, а второй указывает на 
структуру, куда нужно поместить информацию. 

Системные вызовы для управления каталогами 

В этом разделе мы рассмотрим некоторые системные вызовы, относящиеся ско¬ 
рее к каталогам и файловой системе в целом, нежели просто к определенному фай¬ 
лу, как в предыдущем разделе. Первые два вызова, тксН г и гшсііг, соответственно 
создают и удаляют пустые каталоги. Следующий вызов — 1 і пк. Он разрешает од¬ 
ному файлу появляться под двумя или более именами, часто в разных каталогах. 
Этот вызов обычно используется, когда несколько программистов, работающих 
в одной команде, должны совместно использовать один общий файл. Тогда этот 
файл может появиться в каталоге у каждого из программистов, возможно, под дру¬ 
гим именем. Разделение (совместное использование) файла — это не то же самое, 
что копирование файла для каждого члена команды. При разделении файла изме¬ 
нения, производимые одним программистом, немедленно становятся видимыми 
для остальных — все происходит в одном файле. А при создании копии файла по¬ 
следующие изменения не влияют на другие копии этого файла. 

Чтобы увидеть, как работает вызов 1 і пк, рассмотрим ситуацию на рис. 1.19, а. 
Два пользователя, азі и ]іт, имеют свои собственные каталоги азі ирт с файлами. 
Если теперь пользователь ох? запустит программу, содержащую системный вызов 

1 і пк("/изг/ ді гп/тето", "/изг/авГ/поГе"): 

то файл тето в каталоге Джима появится в каталоге Аста под названием поіе. 
Соответственно, / изг/рт/тето и /изг/азі/поіе теперь будут ссылаться на один и 
тот же файл. Хранятся ли каталоги пользователей в каталоге /изг,/изег,/коте или 
где-либо еще, определяется локальным системным администратором. 

Возможно, станет понятнее, что делает системный вызов 1 і пк, если разобраться 
в том, как он работает. Каждый файл в ІШІХ имеет уникальный номер — свой і-но- 
мер, который идентифицирует файл (ібепіійсаііоп — идентификация). І-номер — 
это индекс в таблице і-узлов (і-побез), содержащей по одному на файл. Каждый 
і-узел включает в себя информацию о хозяине файла, о том, какие блоки на диске 




Системные вызовы 


77 


он занимает и т. д. Каталог представляет собой просто файл, содержащий набор 
пар (і-номер, А5СП-имя). В первой версии ІЖІХ под каждый элемент каталога 
было отведено 16 байт: два байта для і-номера и 14 байт для названия. Хотя теперь 
для поддержки длинных имен используется более сложная структура, концепту¬ 
ально каталог все еще остается набором пар (і-номер, А5СП-имя). На рис. 1.19 
файл таіі имеет і-номер, равный 16 и т. д. Вызов Нпк просто создает новый эле¬ 
мент каталога, возможно, с новым именем, используя і-номер существующего 
файла. На рис. 1.19, б два элемента имеют одинаковый і-номер (70) и, таким об¬ 
разом, ссылаются на один и тот же файл. Если впоследствии один из них будет 
удален с помощью системного вызова ипі і пк, другой элемент останется. Если будут 
удалены оба файла, ІЖІХ убедится, что больше нет записей, соответствующих 
этому файлу (поле в таблице і-узлов хранит данные с номером элемента каталога, 
указывающие на файл), и удалит файл с диска. 



Рис. 1.19. Два каталога до присоединения /изг/ііт/тето к каталогу азі (а); те же каталоги 

после вызова Ііпк (б) 


Как упоминалось выше, системный вызов тоипі позволяет объединять в одну 
две файловые системы. Обычная ситуация такова: на жестком диске находится 
корневая файловая система, содержащая двоичные (исполняемые) версии общих 
команд и наиболее часто использующиеся файлы. При этом пользователь может 
вставить в дисковод гибкий диск для чтения файлов. 

При помощи системного вызова тоипі файловую систему с гибкого диска мож¬ 
но присоединить к корневой файловой системе, как показано на рис. 1.20. Типич¬ 
ный оператор на языке С, выполняющий монтирование, выглядит так: 

тоипГГ'/сіеѵ/'ИО" . “ІтѴ. 0); 

где первым параметром является имя специального блочного файла на диске 0, 
второй параметр — это место в дереве, куда будет вмонтирована файловая система, 
а третий параметр говорит о том, монтируется ли встроенная файловая система 
для чтения и записи или только для чтения. 
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Рис. 1 .20. Файловая система: до вызова тоипі (а); после вызова тоипі (б) 
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После вызова тоипЪ доступ к файлу на диске 0 можно получить, просто указав 
его путь из корневого или рабочего каталога, независимо от того, на каком диске 
он находится. В действительности второй, третий и четвертый диски тоже можно 
встроить в любое удобное место в дереве. Вызов тоііпі позволяет объединить съем¬ 
ные носители в единую интегрированную файловую структуру, не заботясь о том, 
на каком из устройств фактически находится файл. Хотя в нашем примере рас¬ 
сматривались гибкие диски, жесткие диски или их части (часто называемые раз¬ 
делами (рагННоп) или младшими устройствами (тіпог беѵісез)) монтируются 
аналогично. Когда файловая система более не нужна, ее можно демонтировать 
с помощью системного вызова шюипЕ 

Разные системные вызовы 

Существует, помимо описанных выше, еще множество системных вызовов. Сей¬ 
час мы рассмотрим только четыре из них. Вызов сМіг изменяет текущий рабочий 
каталог. После вызова 

сИсИгС'/изг/азТ/ТезТ"): 

процедура открытия файла хуг откроет /изг/азі/іезі/хуг. Использование понятия 
рабочего каталога избавляет от необходимости постоянно набирать длинные аб¬ 
солютные пути файлов. 

В ІЖІХ для каждого файла определен режимный код файла, иногда также на¬ 
зываемый модой (тобе), используемый для его защиты. Режимный код включает 
в себя биты чтения-записи-выполнения для владельцев, группы и других пользо¬ 
вателей. Системный вызов сЬтоб предоставляет возможность изменения режим¬ 
ного кода файла. Например, следующий вызов предоставит всем, кроме владель¬ 
ца, доступ к файлу только для чтения; владелец же сможет еще и выполнять файл: 

сИшосК "-Гі 1е". 0644): 

Системный вызов кіП позволяет пользователям и пользовательским процес¬ 
сам посылать сигналы. Если процесс готов принять определенный сигнал, то при 
его прибытии запускается обработчик сигналов. Если же процесс не готов обрабо¬ 
тать сигнал, тогда прибытие сигнала уничтожает процесс (отсюда произошло на¬ 
звание вызова, кііі в переводе означает «убивать, уничтожать»). 

Стандартом Р05ІХ определено несколько процедур, имеющих отношение ко 
времени. Например, ѣіте возвращает текущее время в секундах, причем нулем счи¬ 
тается полночь 1 января 1970 года (имеется в виду начало дня, а не его конец). На 
компьютерах с 32-разрядными словами максимальная величина, которую может 
вернуть Іпте, составляет 2 32 -1 с (используется положительное целое число). Эта 
величина соответствует периоду немногим более 136 лет. Таким образом, в 2106 году 
32-разрядные системы ІЖІХ «сойдут с ума», имитируя знаменитую проблему 
2000 года (Ѵ2К). Если сейчас у вас 32-разрядная система ІЖІХ, мы рекомендуем 
вам поменять ее на 64-разрядную, прежде чем наступит 2106 год. 

ѴѴіпсІоѵѵз ѴѴіп32 АРІ 

До сих пор мы концентрировали свое внимание в первую очередь на системе 
ІЖІХ. Теперь самое время обратить внимание на '\Ѵіпбо\ѵз. В ^Уіпбо\ѵз и ІЖІХ 
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фундаментально отличаются соответствующие модели программирования. Про¬ 
граммы ІІЫІХ состоят из кода, который выполняет те или иные действия, обраща¬ 
ясь к системе с системными запросами для предоставления ему конкретных услуг. 
В противоположность этому программы в \ѴіпсІо\ѵ5 обычно приводятся в действие 
событиями. Основной модуль программы ждет, когда произойдет какое-либо собы¬ 
тие, затем вызывает процедуру для его обработки. Типичными событиями являют¬ 
ся: нажатие клавиши мыши или клавиатуры, передвижение мыши или появление 
гибкого диска в дисководе. Затем обработчики, вызываемые для обработки собы¬ 
тия, переписывают содержимое экрана и внутреннее состояние программы. Все это 
ведет к совершенно отличному от ІЖІХ стилю программирования, но поскольку 
наша книга посвящена функциям и структуре операционной системы, различные 
модели программирования не имеют к нам сейчас особого отношения. 

Конечно, в \ѴЪсІо\Ѵ5 тоже есть системные вызовы. В ІЖІХ вызовы почти один 
к одному идентичны библиотечным процедурам (вспомним геасі), используемым 
для обращения к системным вызовам. Другими словами, для каждого системного 
вызова существует одна библиотечная процедура, обычно с тем же названием, ко¬ 
торая вызывается для обращения к нему. Это было показано на рис. 1.17. Кроме 
того, в стандарте Р05ІХ всего лишь около 100 процедурных вызовов. 

Ситуация в системе \ѴіпсІо\Ѵ5 совершенно иная. Во-первых, фактические сис¬ 
темные вызовы и запускающиеся для их выполнения библиотечные вызовы пол¬ 
ностью разделены. Корпорацией МісгозоЛ определен набор процедур, называемый 
\Ѵіп32 АРІ (Арріісаііоп Ргощат Іпіегіасе — интерфейс прикладных программ). 
Предполагается, что программисты должны использовать его для вызова служб 
операционной системы. Этот интерфейс частично поддерживается всеми верси¬ 
ями \Ѵіпбо\Ѵ5, начиная с \Ѵіпбо\ѵ5 95. Отделяя интерфейс от фактических сис¬ 
темных вызовов, МісгозоЙ поддерживает возможность изменения со временем 
действительных системных вызовов (даже от одной версии к другой), не делая 
при этом недействительными существующие программы. Ситуация на самом деле 
складывается неоднозначная, так как в \Ѵтс1о\Ѵ5 2000 появилось много новых вы¬ 
зовов, ранее недоступных. В этом разделе \Ѵіп32 означает интерфейс, поддержи¬ 
ваемый всеми версиями \ѴіпсІо\ѵ5. 

Количество вызовов в \Ѵіп32 АРІ крайне велико, вызовы исчисляются тыся¬ 
чами. Кроме того, хотя многие из них являются системными, существенное число 
работает целиком в пространстве пользователя. Из-за этого в \Ѵіпбо\Ѵ8 невозмож¬ 
но понять, является ли вызов системным (то есть выполняемым ядром), или про¬ 
сто библиотечным вызовом, который обрабатывается в пространстве пользовате¬ 
ля. В принципе вызов, считающийся системным в одной версии \Ѵіпсіо\ѵ5, может 
выполняться в пользовательском пространстве в других версиях, и наоборот. При 
обсуждении системных вызовов \ѴіпсІо\ѵ5 в этой книге мы будем использовать 
соответствующие процедуры \Ѵіп32, поскольку МісгозоЙ гарантирует, что они не 
будут меняться. Но стоит всегда помнить, что не все они являются настоящими 
системными вызовами (то есть прерываниями с переключением в режим ядра). 

Другое различие заключается в том, что в ІЖІХ графический интерфейс пользо¬ 
вателя (например, X \ѴтсІо\ѵ5 или Моііі) запускается целиком в пользователь¬ 
ском пространстве. Поэтому для вывода на экран достаточно системного вызова 
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ѵѵгііе и несколько других незначительных вызовов. Конечно, существует достаточ¬ 
но большое количество обращений к X ^УіпсІоѵ/5 и СШ, но они не являются сис¬ 
темными вызовами в любом смысле этого слова. 

В противоположность этому \Ѵіп32 АРІ имеет огромное количество вызовов 
для управления окнами, геометрическими фигурами, текстом, шрифтами, полоса¬ 
ми прокрутки, диалоговыми окнами, пунктами меню и другими элементами гра¬ 
фического интерфейса. В том случае, когда графическая подсистема запускается 
в режиме ядра (это верно для большинства версий \ѴтсІо\ѵ5, но не для всех), вы¬ 
зовы являются системными; в противном случае вызовы являются только библио¬ 
течными. Должны ли мы обсуждать эти вызовы в книге или нет? Так как они на 
самом деле не связаны с функциями операционной системы, мы решили этого не 
делать, несмотря на то, что они выполняются ядром. Читателям, интересующимся 
\Ѵіп32 АРІ, мы рекомендуем обратиться к любой из множества книг по этому пред¬ 
мету, например [146, 271 или 302]. 

Даже перечисление всех вызовов \ѴІп32 АРІ выходит за рамки этой книги, 
поэтому мы ограничимся теми из них, которые приблизительно соответствуют 
функциональности вызовов ІЖІХ, перечисленных в табл. 1.1. Эти вызовы пока¬ 
заны в табл. 1.2. 


Таблица 1.2. Вызовы ѴѴіп32 АРІ, приблизительно соответствующие вызовам ШІХ, 
перечисленным в табл. 1.1 


ІШІХ 

ѴѴІП32 

Описание 

Рогк 

СгеаІеРгосезз 

Создать новый процесс 

ѴѴаіІрісІ 

ѴѴаііРогЗіпдІеОЬіесІ 

Ждать завершения процесса 

Ехесѵе 

(нет) 

СгеаіеРгосезз=1огк+ехесѵе 

Ехіі 

ЕхіІРгосезз 

Завершить выполнение 

Ореп 

СгеаІеРІІе 

Создать файл или открыть существующий файл 

СІозе 

СІозеНапсіІе 

Закрыть файл 

Неаб 

НеабРІІе 

Читать данные из файла 

ѴѴгіІе 

ѴѴгіІеРІІе 

Записать данные в файл 

Ьзеек 

ЗеІРіІеРоіпіег 

Передвинуть указатель файла 

Зіаі 

СеіРІІеАКгіЬиІезЕх 

Получить различные атрибуты файла 

Мксііг 

Сгеаіейігесіогу 

Создать новый каталог 

Втсііг 

ИетоѵеРігесІогу 

Удалить пустой каталог 

І_іпк 

(нет) 

ѴѴіп32 не поддерживает связи 

Ііпііпк 

йеіеіерііе 

Удалить существующий файл 

Моипі 

(нет) 

ѴѴіп32 не поддерживает монтирование 

ІІгпоипІ 

(нет) 

ѴѴІп32 не поддерживает монтирование 

сМіг 

ЗеіСиггепЮігесІогу 

Изменить текущую рабочую папку 

сЬтоб 

(нет) 

ѴѴІп32 не поддерживает защиту файла (хотя КІТ поддерживает) 

кіІІ 

(нет) 

ѴѴіп32 не поддерживает сигналы 

Гіте 

СеіІ_осаІТіте 

Получить текущее время 


Теперь кратко пройдемся по списку, представленному в табл. 1.2. Вызов 
СгеаіеРгосезз создает новый процесс. Он комбинирует работу вызовов Гогк и ехесѵе 
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в ІЖІХ. У этого вызова есть множество параметров, определяющих свойства создан¬ 
ных процессов. В \Уіпсіоѵѵ$ нет такой иерархии процессов, как в (ЖIX, поэтому здесь 
нет концепции родительских и дочерних процессов. После создания нового про¬ 
цесса «создатель» и «созданный» становятся равноправными. МаіІРогБі пді еОЬ^есі 
используется для ожидания события. Существует множество событий, которые 
можно ждать. Если параметром указан процесс, тогда вызывающая программа 
ждет завершения определенного процесса. Завершение процесса выполняется 
с помощью вызова ЕхИРгосезз. 

Следующие шесть вызовов оперируют файлами и функционально похожи на 
свои аналоги в ІШІХ, несмотря на то что они имеют различные параметры и дета¬ 
ли. Таким образом, файлы можно открывать, закрывать и читать практически так 
же, как в ІШІХ. Вызовы БеѣРПеРоіпѣег и (ЗеІТНеАІТгіЬійезЕх устанавливают пози¬ 
цию указателя и получают некоторые из атрибутов файла. 

В ^іпсіолѵз также есть каталоги, их создают и удаляют вызовы СгеаІеОігесіогу 
и КешоѵеОі гесѣогу соответственно. Здесь тоже есть понятие текущего каталога, он 
задается с помощью БеѣСиггегйОі гесіогу. Для получения текущего времени исполь¬ 
зуется беНосаІТіте. 

В интерфейсе ^іп32 не существует связанных файлов, монтирования файло¬ 
вых систем, защиты файлов и сигналов, поэтому также нет и вызовов, соответству¬ 
ющих вызовам ІЖІХ. Конечно, в ^іп32 есть огромное количество самых разных 
других вызовов, которых не имеет ІЛѴІХ, особенно относящихся к управлению 
графическим интерфейсом. Однако система ^іпсіолѵз 2000 имеет тщательно проду¬ 
манную систему безопасности и, кроме того, поддерживает связи между файлами. 

Стоит сделать еще одно, последнее замечание относительно \Уіп32. \Уіп32 не 
является полностью единообразным и последовательным интерфейсом. Причиной 
этого явилась необходимость обратной совместимости с ранее использовавшимся 
в ’ѴѴіпсіолѵз 3.x 16-раз рядным интерфейсом. 

Структура операционной системы 

Теперь, когда мы уже видели, как выглядят операционные системы снаружи (то 
есть мы знакомы с программным интерфейсом), самое время заглянуть внутрь. 
Чтобы получить представление обо всем спектре возможных вариантов, в следу¬ 
ющих разделах мы исследуем пять различных использующихся (или использо¬ 
вавшихся ранее) структур. Исследование это нельзя назвать всесторонним, здесь 
лишь рассматривается несколько моделей, применявшихся на практике в разных 
системах. Их пять — монолитные системы, многоуровневые системы, виртуальные 
машины, экзоядро и модель клиент-сервер. 

Монолитные системы 

В общем случае организация монолитной системы представляет собой «большой 
беспорядок». То есть структура как таковая отсутствует. Операционная система 
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написана в виде набора процедур, каждая из которых может вызывать другие, ког¬ 
да ей это нужно. При использовании такой техники каждая процедура системы 
имеет строго определенный интерфейс в терминах параметров и результатов, 
и каждая имеет возможность вызвать любую другую для выполнения некоторой 
необходимой для нее работы. 

Для построения монолитной системы необходимо скомпилировать все отдель¬ 
ные процедуры, а затем связать их в единый объектный файл с помощью компо¬ 
новщика. Здесь, по существу, полностью отсутствует сокрытие деталей реализа¬ 
ции — каждая процедура видит любую другую процедуру (в отличие от структуры, 
содержащей модули, в которой большая часть информации является локальной 
для модуля и процедуры модуля можно вызвать только через специально опреде¬ 
ленные точки входа). 

Однако даже такие монолитные системы могут иметь некоторую структуру. 
При обращении к системным вызовам, поддерживаемым операционной системой, 
параметры помещаются в строго определенные места — регистры или стек, после 
чего выполняется специальная команда прерывания, известная как вызов ядра 
или вызов супервизора. Эта команда переключает машину из режима пользова¬ 
теля в режим ядра и передает управление операционной системе, что видно на 
шаге 6 рис. 1.17. Затем операционная система проверяет параметры вызова, чтобы 
определить, какой системный вызов должен быть выполнен. После этого опера¬ 
ционная система обращается к таблице как к массиву с номером системного вызо¬ 
ва в качестве индекса. В к-и элементе таблицы содержится ссылка на процедуру 
обработки системного вызова к (шаг 7 на рис. 1.17). Такая организация операци¬ 
онной системы предполагает следующую структуру: 

1. Главная программа, которая вызывает требуемую служебную процедуру. 

2. Набор служебных процедур, выполняющих системные вызовы. 

3. Набор утилит, обслуживающих служебные процедуры. 

В этой модели для каждого системного вызова имеется одна служебная проце¬ 
дура. Утилиты выполняют функции, которые нужны нескольким служебным про¬ 
цедурам. Деление процедур на три уровня показано на рис. 1.21. 



Рис. 1.21. Простая модель монолитной системы 
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Многоуровневые системы 

Обобщением подхода, изображенного на рис. 1.21, является организация операци¬ 
онной системы в виде иерархии уровней. Первой системой, построенной таким 
образом, была система ТНЕ, созданная в ТесЬпізсЬе Но§езсЬоо1 ЕіпйЬоѵеп (Ни¬ 
дерланды) Э. Дейкстрой (Е. 4У. Оцкзіга) и его студентами в 1968 году. Она была 
простой пакетной системой для голландского компьютера ЕІесСго1о§іса Х8, память 
которого состояла из 32 К 27-разрядных слов. Система включала б уровней, как 
показано в табл. 1.3. Уровень 0 занимался распределением времени процессора, 
переключая процессы при возникновении прерывания или при срабатывании тай¬ 
мера. Над уровнем 0 система состояла из последовательных процессов, каждый из 
которых можно было запрограммировать, не заботясь о том, что на одном про¬ 
цессоре запущено несколько процессов. Другими словами, уровень 0 обеспечивал 
базовую многозадачность процессора. 

Таблица 1.3. Структура операционной системы ТНЕ 

Уровень Функция 

5 Оператор 

4 Программы пользователя 

3 Управление вводом-выводом 

2 Связь оператор-процесс 

1 Управление памятью и барабаном 

О Распределение процессора и многозадачность 


Уровень 1 управлял памятью. Он выделял процессам пространство в оператив¬ 
ной памяти и на магнитном барабане объемом 512 К слов для тех частей процес¬ 
сов (страниц), которые не помещались в оперативной памяти. Процессы более 
высоких уровней не заботились о том, находятся ли они в данный момент в памя¬ 
ти или на барабане. Программное обеспечение уровня 1 обеспечивало попадание 
страниц в оперативную память по мере необходимости. 

Уровень 2 управлял связью между консолью оператора и процессами. Таким 
образом, все процессы выше этого уровня имели свою собственную консоль опе¬ 
ратора. Уровень 3 управлял устройствами ввода-вывода и буферизовал потоки 
информации к ним и от них. Любой процесс выше уровня 3, вместо того чтобы 
работать с конкретными устройствами, с их разнообразными особенностями, мог 
обращаться к абстрактным устройствам ввода-вывода, обладающим удобными для 
пользователя характеристиками. На уровне 4 работали пользовательские програм¬ 
мы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, 
ни об управлении устройствами ввода-вывода. Процесс системного оператора раз¬ 
мещался на уровне 5. 

Дальнейшее обобщение многоуровневой концепции было сделано в операцион¬ 
ной системе МШЛ1С5. В ней уровни представляли собой серию концентрических 
колец, где внутренние кольца являлись более привилегированными, чем внешние. 
Когда процедура внешнего кольца хотела вызвать процедуру кольца, лежащего 
внутри, она должна была выполнить эквивалент системного вызова, то есть коман- 
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ду ТКАР, параметры которой тщательно проверяются перед тем, как выполняется 
вызов. Хотя операционная система в МШЛ1С5 являлась частью адресного про¬ 
странства каждого пользовательского процесса, аппаратура обеспечивала защиту 
данных на уровне сегментов памяти, разрешая или запрещая доступ к индивиду¬ 
альным процедурам (в действительности к сегментам памяти) для записи, чтения 
или выполнения. 

Стоит отметить, что в системе ТНЕ многоуровневая схема представляла собой 
исключительно конструкционное решение и все части системы были, в конечном 
счете, связаны в один объектный файл, а в МШЛ1С5 механизм разделения колец 
действовал во время исполнения на аппаратном уровне. 

Преимущество подхода МШТПСЗ заключается в том, что его можно расши¬ 
рить и на структуру пользовательских подсистем. Например, профессор может 
написать программу для тестирования и оценки студенческих программ и запустить 
ее в кольце п, в то время как студенческие программы будут работать в кольце п + 1, 
так что они не смогут изменить свои оценки. 

Виртуальные машины 

Исходная версия 05/360 была системой исключительно пакетной обработки. 
Однако множество пользователей 05/360 желали работать в системе с разделе¬ 
нием времени, поэтому различные группы программистов как в самой корпора¬ 
ции ІВМ, так и вне ее решили написать для этой машины системы с разделением 
времени. Официальная система с разделением времени от ІВМ, которая называ¬ 
лась Т55/360, поздно вышла в свет и оказалась настолько громоздкой и медлен¬ 
ной, что на нее перешли немногие. В конечном счете от нее отказались, но уже 
после того, как ее разработка потребовала около 50 млн долларов [135]. Группа из 
научного центра ІВМ в Кембридже, штат Массачусетс, разработала в корне отли¬ 
чающуюся от нее систему, которую ІВМ в результате приняла как законченный 
продукт. Сейчас она широко используется на еще оставшихся мэйнфреймах. 

Эта система, в оригинале называвшаяся СР/СМ5, а позже переименованная 
в ѴМ/370 [279], была основана на следующем проницательном наблюдении: сис¬ 
тема с разделением времени обеспечивает (1) многозадачность и (2) расширенную 
машину с более удобным интерфейсом, чем тот, что предоставляется оборудова¬ 
нием напрямую. ѴМ/370 основана на полном разделении этих двух функций. 

Сердце системы, называемое монитором виртуальной машины, работает с обо¬ 
рудованием и обеспечивает многозадачность, предоставляя верхнему слою не одну, 
а несколько виртуальных машин, как показано на рис. 1.22. Но, в отличие от всех 
других операционных систем, эти виртуальные машины не являются расширен¬ 
ными. Они не поддерживают файлы и прочие удобства, а представляют собой точ¬ 
ные копии голой аппаратуры, включая режимы ядра и пользователя, ввод-вывод 
данных, прерывания и все остальное, присутствующее на реальном компьютере. 

Поскольку каждая виртуальная машина идентична настоящему оборудованию, 
на каждой из них может работать любая операционная система, которая запуска¬ 
ется прямо на аппаратуре. На разных виртуальных машинах могут (а зачастую так 
и происходит) функционировать различные операционные системы. На некоторых 
из них для обработки пакетов и транзакций работают потомки 05/360, а на других 
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для интерактивного разделения времени пользователей работает однопользова¬ 
тельская интерактивная система СМ5 (Сопѵегзаііопаі Мопііог Зузіет — система 
диалоговой обработки). 


Команды ввода-вывода 
Прерывания 


Виртуальные 370-е 





—►! СМ5 

СМ5 

СМ5’Ч— 


ѴМ/370 


«Галое» оборудование 370 


Системные вызовы 
Прерывания 


Рис. 1.22. Структура ѴМ/370 с системой СМ5 


Когда программа операционной системы СМ3 выполняет системный вызов, 
он прерывает операционную систему на своей собственной виртуальной машине, 
а не на ѴМ/370, как произошло бы, если бы он работал на реальной машине вместо 
виртуальной. Затем СМ3 выдает обычные команды ввода-вывода для чтения сво¬ 
его виртуального диска или другие команды, которые ей могут понадобиться для 
выполнения вызова. Эти команды ввода-вывода перехватываются ѴМ/370, кото¬ 
рая выполняет их в рамках моделирования реального оборудования. При полном 
разделении функций многозадачности и предоставления расширенной машины 
каждая часть может быть намного проще, гибче и удобней для обслуживания. 

Идея виртуальной машины очень часто используется в наши дни, но в не¬ 
сколько другом контексте: для работы старых программ, написанных для системы 
МЗ-ООЗ на Репііиш (или на других 32-разрядных процессорах Іпіеі). При разра¬ 
ботке компьютера Репііиш и его программного обеспечения обе компании, Іпіеі 
и МісгозоЙ, понимали, что возникнет острая потребность в работе старых программ 
на новом оборудовании. Поэтому корпорация Іпіеі создала на процессоре Репііиш 
режим виртуального процессора 8086. В этом режиме машина действует как 8086 
(которая с точки зрения программного обеспечения идентична 8088), включая 
16-разрядную адресацию памяти с ограничением объема памяти в 1 Мбайт. 

Такой режим используется системой ѴТпсІохѵв и другими операционными сис¬ 
темами для запуска программ МЗ-ООЗ. Программы запускаются в режиме вирту¬ 
ального процессора 8086. Пока они выполняют обычные команды, они работают 
напрямую с оборудованием. Но когда программа пытается обратиться по преры¬ 
ванию к операционной системе, чтобы сделать системный вызов, или пытается 
напрямую осуществить ввод-вывод данных, происходит прерывание с переклю¬ 
чением на монитор виртуальной машины. 

Возможны два варианта устройства. Первый: сама система МЗ-ООЗ загружена 
в адресное пространство виртуальной машины 8086, так что монитор виртуальной 
машины только отсылает прерывания назад к МЗ-ООЗ, как это происходит на ре¬ 
альной 8086. Когда затем МЗ-ООЗ пытается самостоятельно осуществить ввод- 
вывод, операция перехватывается и выполняется монитором виртуальной машины. 

В другом варианте монитор виртуальной машины перехватывает первое пре¬ 
рывание и сам выполняет ввод-вывод, так как он знает все системные вызовы 
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МЗ-НОЗ и имеет представление о том, что должно делать каждое прерывание. 
Этот вариант не столь безупречен, как первый, потому что, в отличие от первого 
варианта, он корректно моделирует только М5-Э05 и никакие другие операци¬ 
онные системы. С другой стороны, он намного быстрее работает, так как избегает 
проблем запуска М5-Э05 для выполнения ввода-вывода. Существует еще один 
недостаток фактического запуска М5-Э05 в режиме виртуальной 8086: МЗ-БОЗ 
очень часто оперирует флагом разрешения/запрещения прерывания, а моделиро¬ 
вание этого требует больших затрат. 

Стоит отметить, что ни один из двух описанных методов в действительности 
не является те же самым, чем была ѴМ/370, потому что смоделированная машина 
представляет собой только 8086, а не полноценный Репііит. В системе ѴМ/370 
можно было запустить на виртуальной машине саму ѴМ/370. На РепГіит нельзя 
запустить, скажем, операционную систему ЛѴіпсіохѵз на виртуальной 8086, потому 
что не существует версий ^іпбо\Ѵ5, работающих на этой машине. Даже для самых 
старых версий ЛѴіпсіохѵз необходим как минимум 286-й процессор, а моделирова¬ 
ние 286 не поддерживается (не говоря уже об эмуляции Репііиш). Однако, если 
немного модифицировать двоичный код ЛѴіпсіохѵз, подобная модель становится 
возможна, и даже возможна ее коммерческая реализация. 

Кроме того, виртуальные машины используются, правда, несколько другим 
способом, для работы программ ]аѵг. Когда корпорация Зип МісгокузГетз приду¬ 
мала язык программирования ^ѵа, она также разработала виртуальную машину 
(то есть архитектуру компьютера), называемую ДѴМ Оаѵа Ѵігіиаі МасЬіпе — 
виртуальная машина^ѵа). Компилятор ^ѵа выдает код для^М, который затем 
обычно выполняется программным интерпретатором }ѴМ. Преимущество этого 
подхода заключается в том, что код ,|ѴМ можно передавать через Іпіегпеі на 
любой компьютер, имеющий интерпретатор ,|ѴМ, и запускать там. Если бы ком¬ 
пилятор выдавал двоичные программы, например, для компьютеров ЗРАКС или 
Репііиш, их было бы нельзя куда-либо передать и запустить в работу так просто, 
как зто происходит с,|ѴМ. (Конечно, компания Зип могла бы разработать компи¬ 
лятор, который выдавал бы двоичные коды 5РАКС, и затем использовать интер¬ 
претатор ЗРАКС, но структура ДѴМ намного проще для интерпретации.) Другое 
преимущество ,|ѴМ заключается в том, что когда интерпретатор реализован долж¬ 
ным образом, что вовсе не тривиально, приходящие ДѴМ-программы можно про¬ 
верить в целях безопасности и затем запустить в защищенной среде, так что эти 
программы не смогут похитить данные или причинить какой-нибудь иной вред. 

Экзоядро 

В системе ѴМ/370 каждый пользователь получает точную копию настоящей ма¬ 
шины. На Репііит, в режиме виртуальной машины 8086, каждый пользователь 
получает точную копию другой машины. Развив эту идею дальше, исследователи 
из Массачусетсского технологического института изобрели систему, которая обес¬ 
печивает каждого пользователя абсолютной копией реального компьютера, но с под¬ 
множеством ресурсов [111]. Например, одна виртуальная машина может получить 
блоки на диске с номерами от 0 до 1023, следующая — от 1024 до 2047 и т. д. 
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На нижнем уровне в режиме ядра работает программа, которая называется эк¬ 
зоядро (ехокетеі). В ее задачу входит распределение ресурсов для виртуальных 
машин, а после этого проверка их использования (то есть отслеживание попыток 
машин использовать чужой ресурс). Каждая виртуальная машина на уровне пользо¬ 
вателя может работать с собственной операционной системой, как на ѴМ/370 или 
виртуальных 8086-х для Репіііші, с той разницей, что каждая машина ограничена 
набором ресурсов, которые она запросила и которые ей были предоставлены. 

Преимущество схемы экзоядра заключается в том, что она позволяет обойтись 
без уровня отображения. При других методах работы каждая виртуальная маши¬ 
на считает, что она использует свой собственный диск с нумерацией блоков от 0 
до некоторого максимума. Поэтому монитор виртуальной машины должен поддер¬ 
живать таблицы преобразования адресов на диске (и всех других ресурсов). Необ¬ 
ходимость преобразования отпадает при наличии экзоядра, которому нужно толь¬ 
ко хранить запись о том, какой виртуальной машине выделен данный ресурс. Такой 
подход имеет еще одно преимущество: он отделяет многозадачность (в экзоядре) 
от операционной системы пользователя (в пространстве пользователя) с меньши¬ 
ми затратами, так как для этого ему необходимо всего лишь не допускать вмеша¬ 
тельства одной виртуальной машины в работу другой. 

Модель клиент-сервер 

Сис тема ѴМ/370 сильно выигрывает в простоте благодаря переносу значитель¬ 
ной части кода традиционной операционной системы (обеспечивающего расши¬ 
ренную машину) в верхний уровень, систему СМ5. Однако ѴМ/370 и при этом 
останется сложной комплексной программой, потому что моделирование несколь¬ 
ких виртуальных 370-х машин само по себе не так просто (особенно если вы хоти¬ 
те сделать это достаточно эффективно). 

В развитии современных операционных систем наблюдается тенденция в сто¬ 
рону дальнейшего переноса кода в верхние уровни и удалении при этом всего, что 
только возможно, из режима ядра, оставляя минимальное микроядро. Обычно это 
осуществляется перекладыванием выполнения большинства задач операционной 
системы на средства пользовательских процессов. Получая запрос на какую-либо 
операцию, например чтение блока файла, пользовательский процесс (теперь назы¬ 
ваемый обслуживаемым процессом или клиентским процессом) посылает запрос 
серверному (обслуживающему) процессу, который его обрабатывает и высылает 
назад ответ. 

В модели, показанной на рис. 1.23, в задачу ядра входит только управление свя¬ 
зью между клиентами и серверами. Благодаря разделению операционной систе¬ 
мы на части, каждая из которых управляет всего одним элементом системы (фай¬ 
ловой системой, процессами, терминалом или памятью), все части становятся 
маленькими и управляемыми. К тому же, поскольку все серверы работают как 
процессы в режиме пользователя, а не в режиме ядра, они не имеют прямого дос¬ 
тупа к оборудованию. Поэтому если происходит ошибка на файловом сервере, 
может разрушиться служба обработки файловых запросов, но это обычно не 
приводит к остановке всей машины целиком. 
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Рис. 1.23. Модель клиент-сервер 


Другое преимущество модели клиент-сервер заключается в ее простой адапта¬ 
ции к использованию в распределенных системах (рис. 1.24). Если клиент обща¬ 
ется с сервером, посылая ему сообщения, клиенту не нужно знать, обрабатывается 
ли его сообщение локально на его собственной машине или оно было послано по 
сети серверу на удаленной машине. С точки зрения клиента происходит одно и то 
же в обоих случаях: запрос был послан, и на него получен ответ. 

Рассказанная выше история о ядре, управляющем передачей сообщений от кли¬ 
ентов к серверам и назад, не совсем реалистична. Некоторые функции операцион¬ 
ной системы, такие как загрузка команд в регистры физических устройств ввода- 
вывода, трудно, если вообще возможно, выполнить из программ в пространстве 
пользователя. Есть два способа разрешения этой проблемы. Первый заключается 
в том, что некоторые критические серверные процессы (например, драйверы уст¬ 
ройств ввода-вывода) действительно запускаются в режиме ядра, с полным дос¬ 
тупом к аппаратуре, но при этом общаются с другими процессами при помощи 
обычной схемы передачи сообщений. 

Второй способ состоит в том, чтобы встроить минимальный механизм обра¬ 
ботки информации в ядро, но оставить принятие политических решений за серве¬ 
рами в пользовательском пространстве [202]. Например, ядро может опознавать 
сообщения, посланные по определенным адресам. Для ядра это означает, что нуж¬ 
но взять содержимое сообщения и загрузить его, скажем, в регистры ввода-вывода 
некоторого диска для запуска операции чтения диска. В этом примере ядро даже 
может не обследовать байты сообщения, если они оказались допустимы или ос¬ 
мысленны; оно может вслепую копировать их в регистры диска. (Очевидно, долж¬ 
на использоваться некоторая схема, ограничивающая круг процессов, имеющих 
право отправлять подобные сообщения.) Разделение между механизмом и поли¬ 
тикой является очень важным понятием, встречающимся в операционных систе¬ 
мах в различном контексте постоянно. 


Машина 1 Машина 2 Машина 3 Машина 4 



Сообщение от клиента серверу 


Рис. 1.24. Модель клиент-сервер в распределенной системе 
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Исследования в области 
операционных систем 

Кибернетика — это быстро прогрессирующая область, поэтому, говоря о ней, край¬ 
не тяжело предсказывать будущее. Исследователи в университетах и коммерчес¬ 
ких исследовательских лабораториях постоянно выдают новые идеи, некоторые 
из них не развиваются дальше, а другие закладываются в основу будущих про¬ 
граммных продуктов и оказывают огромное влияние на производителей и пользо¬ 
вателей. Отличить первые от вторых оказывается значительно легче задним умом, 
нежели в режиме реального времени. Отделить зерна от плевел трудно, поэтому 
часто проходит 20-30 лет между зарождением идеи и ее расцветом. 

Например, когда президент Эйзенхауэр (ЕізепЬо\ѵег) учредил в 1958 году в Ми¬ 
нистерстве обороны управление АКРА (Асіѵапсесі КезеагсЬ Ргсуесіз А§епсу — уп¬ 
равление перспективных исследовательских программ), он пытался не допустить 
уничтожения армией флота и военно-воздушных сил из-за проблем исследователь¬ 
ского бюджета Пентагона. Он вовсе не пытался изобрести Интернет. Но среди 
прочего АКРА создала фонд для исследований некоторых университетов, посвя¬ 
щенных тогда еще неясной идее пакетной коммутации, которая в скором времени 
легла в основу первой экспериментальной сети с коммутацией пакетов АКР АИЕТ. 
Она появилась в 1969 году. Вскоре другие финансируемые АКРА исследователь¬ 
ские сети присоединились к АКРАИЕТ, и так родился Интернет (Іпіегпеі). Затем 
Интернет успешно использовался в течение 20 лет академическими исследовате¬ 
лями. Они посылали друг другу письма по электронной почте. В начале 1990-х 
годов Тим Бернерс-Ли (Тіш Вегпегз-Бее) изобрел Всемирную паутину (\Ѵог1с1 \Уіс1е 
ІУеЬ) в исследовательской лаборатории СЕНЫ в Женеве, а Марк Андресен (Маге 
Апсігеезеп) в университете Иллинойса написал для нее графический браузер. Пос¬ 
ле этого Интернет заполнился болтающими подростками, чего явно не ожидал 
президент Эйзенхауэр. 

Исследования в области операционных систем также привели к драматичес¬ 
ким изменениям в практических системах. Как уже говорилось ранее, все первые 
коммерческие компьютерные системы были системами пакетной обработки до тех 
пор, пока в начале 60-х в Массачусетсском технологическом институте не изобре¬ 
ли интерактивные системы с разделением времени. Компьютеры были текстовы¬ 
ми машинами, пока в конце 60-х Даг Энгельбарт (Эои§ Еп§е1ЬагС) из Стэнфорд¬ 
ского исследовательского института не изобрел мышь и графический интерфейс 
пользователя. Кто знает, что появится вслед за этим? 

В этом и последующих разделах книги мы кратко опишем часть из исследо¬ 
ваний в области операционных систем, которые имели место за последние 5-10 лет, 
чтобы дать представление о том, что может появиться в будущем. Это введение, 
конечно, не является всеобъемлющим и в основном базируется на статьях, опуб¬ 
ликованных в лучших исследовательских журналах и материалах конференций, 
потому что эти идеи, по крайней мере, пережили тщательный беспристрастный 
процесс анализа перед публикацией. Большинство научных статей, цитируемых 
в посвященных исследованиям разделах, были опубликованы либо ассоциацией 
по вычислительной технике АСМ, либо компьютерным обществом ІЕЕЕ, либо 
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Глава 1. Введение 


ІІ8ЕШХ. Кроме того, они доступны в Интернете для членов этих организаций, 
в том числе студентов. За дополнительной информацией об этих организациях и их 
цифровых библиотеках следует обращаться на следующие сайты: 

АСМ Иі:1:р://ѵѵѵѵѵѵ.аст.огд 

ІЕЕЕ Сотриіег Зосіеіу Ж:1:р://ѵѵѵѵѵѵ.сотриІег.огд 
И5ЕМХ (ШртУтлм.изепіх.огд 

На самом деле все исследователи понимают, что современные операционные 
системы массивны, не гибки, ненадежны, не обеспечивают защиты информации и 
изобилуют ошибками, причем некоторые системы в большей степени, чем осталь¬ 
ные (названия не сообщаются, чтобы защититъ виновников). Естественно, огром¬ 
ное количество исследований было посвящено построению гибкой и надежной 
системы. Многие исследования касаются систем микроядра. Ядра таких систем 
имеют минимальные размеры, поэтому есть шанс, что их смогут целиком отладить 
и сделать надежными. При этом такие системы гибки, потому что большая часть 
операционной системы работает как процессы пользовательского режима и по¬ 
этому их легко переместить или адаптировать к новым условиям, возможно, даже 
во время работы. Обычно в задачу микроядра входит только управление на низ¬ 
ком уровне и передача сообщений между процессами пользователя. 

Микроядра первого поколения, такие как АшоеЬа [324], СЬошз [282], МасЬ [4] 
и V [66], доказали, что эти системы можно построить и заставить работать. Второе 
поколение пытается доказать, что они не только работают, но и делают это с высо¬ 
кой производительностью [119, 147, 208, 209, 270, 371]. Основываясь на опубли¬ 
кованных измерениях, можно утверждать, что эта цель достигнута. 

Множество исследований в области ядра в наши дни фокусируется на конст¬ 
руировании расширяемых операционных систем. Это обычно системы с микрояд¬ 
ром, в которых поддерживается возможность их расширения или переделки в не¬ 
котором направлении. Такими примерами являются Еіике [121], Рагашесіиш [137], 
8РШ [28] и Ѵіпо [299]. Некоторые исследователи также ищут возможности рас¬ 
ширения существующих систем [126]. Многие из этих систем позволяют пользо¬ 
вателям добавлять свой собственный код к ядру, но при этом встает очевидная 
проблема обеспечения безопасности надстроек пользователя. Среди методов разре¬ 
шения этих проблем встречаются такие, как интерпретация расширений, изоляция 
на время выполнения загружаемого удаленного кода в ограниченную среду, так 
называемую «песочницу», использование языков, обеспечивающих типовую 
безопасность, и снабжение исполняемых программ электронной подписью [137, 
306]. В [100] представлена другая точка зрения: на обеспечение безопасности рас¬ 
ширяемых пользователями систем тратится слишком много усилий. По мнению 
авторов, исследователи должны вычислить, какие надстройки полезны, и затем 
сделать их нормальной частью ядра, не предоставляя пользователям возможнос¬ 
тей расширять ядро на лету. 

Хотя один подход к улучшению огромных, содержащих массу ошибок, нена¬ 
дежных операционных систем состоит в уменьшении их размеров, существует вто¬ 
рой, более радикальный метод — вообще устранить операционную систему. Он 
был взят на вооружение группой Каашойка (КаазЬоек) в Массачусетсском техно- 
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логическом институте в их работе над экзоядром. Идея состоит в том, чтобы оста¬ 
вить тонкий слой программного обеспечения, работающего напрямую с аппарату¬ 
рой, все действия которого заключаются в надежном распределении ресурсов ап¬ 
паратуры между пользователями. Например, оно должно решать, кто и какую часть 
диска получает в пользование, куда должны доставляться приходящие сетевые 
пакеты. Все остальное оставляется на усмотрение процессов пользовательского 
уровня, что делает возможным построение как универсальных, так и узкоспециа¬ 
лизированных систем [ПО, 108,168]. 


Краткий обзор следующих глав 

Итак, мы завершили введение и описали общие моменты операционных систем. 
Теперь пришло время разобраться в деталях. Глава 2 посвящена процессам. Здесь 
обсуждаются их свойства и то, как они общаются друг с другом, а также представ¬ 
лено несколько подробных примеров межпроцессного общения и того, как можно 
избежать некоторых ошибок. 

В главе 3 говорится о взаимоблокировке. В этой главе мы дали некоторое пред¬ 
ставление о том, что такое взаимоблокировка, но этой теме следует посвятить от¬ 
дельную главу. Кроме того, обсуждаются способы, позволяющие предупредить или 
избежать взаимоблокировки. 

В главе 4 мы детально изучим управление памятью. Будет исследована важная 
часть виртуальной памяти наряду с тесно связанными с ней идеями разбиения 
памяти на страницы и сегменты. 

Вводу-выводу посвящена глава 5. В ней будут рассмотрены концепции зави¬ 
симости и независимости от устройств. В качестве примеров мы будем использо¬ 
вать такие важные устройства, как диски, клавиатуры и мониторы. 

Затем в главе 6 мы поговорим на очень важную тему файловых систем. Ведь 
с файловой системой пользователь чаще всего имеет дело. Мы рассмотрим и ин¬ 
терфейс файловой системы, и ее реализацию. 

На этом мы завершим изучение основных принципов работы однопроцессор¬ 
ных операционных систем. Однако мы можем рассказать еще многое, особенно о 
расширенных возможностях. Глава 7 посвящена изучению мультимедийных сис¬ 
тем, имеющих ряд свойств и требований, отличающихся от традиционных опера¬ 
ционных систем. Природа мультимедиа, кроме всего прочего, оказывает влияние 
на планирование и файловую систему. Есть еще одна тема для обсуждения — сис¬ 
темы с несколькими процессорами, включая многопроцессорные системы, парал¬ 
лельные компьютеры и распределенные системы. Ее мы рассмотрим в главе 8. 

Чрезвычайно важному вопросу безопасности операционных систем посвяще¬ 
на глава 9. Среди прочих вопросов в этой главе обсуждаются различные виды по¬ 
тенциальной опасности (например, вирусы и черви), механизмы защиты и моде¬ 
ли охраны. 

Затем мы изучим некоторые существующие операционные системы: ІЖІХ 
(глава 10) и \Уішіо\ѵ5 2000 (глава И). Книга заканчивается главой 12, содержащей 
некоторые соображения по поводу проектирования операционных систем. 
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Единицы измерения 

Чтобы избежать путаницы в будущем, необходимо особо отметить то, что в этой 
книге, как книге по науке о компьютерах вообще, используются единицы метри¬ 
ческой системы вместо традиционных английских единиц измерения (система 
фарлонг-стоун-дюжина). Основные метрические префиксы перечислены в табл. 1.4. 
Обычно префиксы сокращаются до первых букв, причем, если единица измере¬ 
ния больше 1, используются заглавные буквы. Например, база данных размером 
в 10 Тбайт занимает около ІО 12 байт на диске, а часы с интервалом в 100 пс будут 
тикать каждую ІО" 12 с. Так как приставки милли- и микро- начинаются с буквы «м», 
нужно было выбрать для них разные сокращения. Обычно для милли- использу¬ 
ется «м», а для микро— сокращение «мк». 


Таблица 1.4. Основные метрические префиксы 


Пока- Явный вид 

затель 

Пре¬ 

фикс 

Пока- Явный вид 
затель 

Пре¬ 

фикс 

ю- 3 

0,001 

милли 

ІО 3 

1000 

Кило 

ю- 6 

0,000001 

микро 

10 е 

1 000 000 

Мега 

ІО- 9 

0,000000001 

нано 

ІО 9 

1 000 000 000 

Гига 

ІО- 12 

0,000000000001 

лико 

10 12 

1 000 000 000 000 

Тера 

ІО- 15 

0,000000000000001 

фемто 

ІО 15 

1 000 000 000 000 000 

Пета 

10-18 

0,0000000000000000001 

атто 

ІО 18 

1 000 000 000 000 000 000 

Екза 

ІО- 2 ' 

0,0000000000000000000001 

зепто 

ІО 21 

1 000 000 000 000 000 000 000 

Зетта 

ІО- 24 

0,0000000000000000000000001 

йокто 

ІО 24 

1 000 000 000 000 000 000 000 000 

Йотта 


При измерении размеров памяти в компьютерной промышленности принято 
использовать единицы, значения которых несколько отличаются от общеприня¬ 
тых. Здесь Кило обозначает 2 10 (1024), то есть немного больше, чем ІО 3 (1000), но 
память всегда измеряется в степенях двойки. Таким образом, 1 Кбайт содержит 
1024 байта, а не 1000 байт. Точно так же 1 Мбайт содержит 2 20 (1 048 576) байт, 
а 1 Гбайт памяти равен 2 30 байт (1 073 741 824). Однако коммуникационная линия, 
передающая 1 Кбит/с, на самом деле передает 1000 бит/с, а 10-мегабитная локальная 
сеть работает со скоростью 10 000 000 бит/с, потому что эти скорости не являются 
степенью двойки. К сожалению, многие люди смешивают эти две системы, особен¬ 
но когда говорят о размерах диска. Чтобы избежать неясности, мы будем исполь¬ 
зовать символы Кбайт, Мбайт и Гбайт для 2 10 , 2 20 и 2 30 соответственно, а Кбит/с, 
Мбит/с и Гбит/с для ІО 3 , 10 6 и ІО 9 бит/с соответственно. 


Резюме 

Операционную систему можно рассматривать с двух точек зрения: как менеджер 
ресурсов и как расширенную машину. Как менеджер ресурсов операционная систе¬ 
ма рационально управляет различными частями системы. С точки зрения расши¬ 
ренной машины, работа операционной системы состоит в предоставлении пользо¬ 
вателям виртуальной машины, более удобной, чем настоящий компьютер. 
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Операционные системы имеют достаточно долгую историю развития, которая 
начинается с тех дней, когда операционные системы заменили оператора, и про¬ 
должается до современных многозадачных систем. Большое значение имеют ран¬ 
ние системы пакетной обработки, многозадачные системы и системы для персо¬ 
нальных компьютеров. 

Поскольку операционные системы тесно взаимодействуют с оборудованием, 
некоторые знания об аппаратуре могут оказаться очень полезны для понима¬ 
ния работы операционной системы. Компьютеры состоят из процессоров, памяти 
и устройств ввода-вывода. Все эти части соединены шинами. 

Основными понятиями, на которых построена операционная система, являют¬ 
ся процессы, управление памятью, управление вводом-выводом, файловая систе¬ 
ма и безопасность. Каждое из них будет разобрано в соответствующей главе. 

Сердцем любой операционной системы является набор системных вызовов, 
которые она может обработать. Они говорят о том, что реально делает операцион¬ 
ная система. Мы рассмотрели четыре группы системных вызовов для ІЖІХ. Пер¬ 
вая группа работает с созданием и завершением процессов. Вторая группа пред¬ 
назначена для чтения и записи файлов. Третья нужна для управления каталогами. 
Четвертая включила в себя различные другие вызовы. 

Операционная система может быть структурирована несколькими способами. 
Наиболее общими выделяемыми при структурировании понятиями являются: 
монолитные системы, иерархия слоев, система виртуальных машин, экзоядро или 
использование модели клиент-сервер. 


Вопросы 

1. Каковы две главные функции операционной системы? 

2. Что такое многозадачность? 

3. Что такое подкачка данных (зроо1іп§)? Как вы считаете, будут ли передо¬ 
вые персональные компьютеры иметь в будущем подкачку данных в каче¬ 
стве стандартного элемента? 

4. На ранних компьютерах чтение или запись каждого байта данных управля¬ 
лось напрямую центральным процессором (то есть тогда не было прямого 
доступа к памяти — БМА). Какой смысл имеет это понятие для многоза¬ 
дачности? 

5. Почему системы с разделением времени не были широко распространены 
на компьютерах второго поколения? 

6. Идея семейства компьютеров родилась в 60-е годы вместе с появлением мэйн¬ 
фреймов серии ІВМ ЗувСеш/ЗбО. Сейчас эта идея считается устаревшей или 
все еще имеет силу? 

7. Одной из причин, по которой на начальной стадии очень медленно распро¬ 
странялся графический интерфейс (СШ), была высокая стоимость необхо¬ 
димого оборудования. Сколько нужно оперативной видеопамяти для под¬ 
держки монохромного текстового экрана размером 25 х 80 строк? И сколько 
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необходимо для 24-битового цветного отображения на экране размером 
1024 х 768 пикселов? Какова была стоимость такой видеопамяти в ценах 
1980 года (5 долларов за килобайт)? Сколько она стоит сейчас? 

8. Какая из следующих команд должна быть разрешена только в режиме ядра: 

а) отключение всех прерываний; 

б) чтение счетчика даты/времени; 

в) изменения счетчика даты/времени; 

г) изменение схемы распределения памяти. 

9. Перечислите основные различия между операционной системой для персо¬ 
нального компьютера и для мэйнфрейма. 

10. В компьютере есть конвейер, состоящий из четырех ступеней. Каждая из них 
выполняет свою работу за одно и то же время, а именно, за 1 нс. Сколько 
команд в секунду может выполнить машина? 

11. Внимательный рецензент замечает несущественную орфографическую 
ошибку в рукописи книги по операционным системам, которую собирают¬ 
ся печатать. Книга состоит примерно из 700 страниц, на каждой 50 строк по 
80 знаков. Сколько времени займет сканирование текста, если копия будет 
целиком размещаться на каждом из уровней памяти, представленных на 
рис. 1.7? Для методов внутреннего хранения считаем, что время доступа 
дано на знак, для диска дано время предположительно на блок из 1024 зна¬ 
ков и для ленты полагаем, что данное время означает последовательный 
доступ к данным, с той же самой скоростью, что и для диска. 

12. На рис. 1.9 блок управления памятью ММИ сравнивает входящий (вир¬ 
туальный) адрес с предельным регистром, вызывая ошибку, если адрес 
слишком большой. Альтернативным решением будет сначала сложить вир¬ 
туальный адрес с индексным регистром и затем сравнить результат (физи¬ 
ческий адрес) с предельным регистром. Эквивалентны ли эти два метода 
логически? Эквивалентны ли эти они с точки зрения производительности? 

13. Когда пользовательская программа выдает системный вызов, чтобы прочи¬ 
тать или записать файл с диска, она сопровождает его информацией о том, 
какой файл ей нужен, указателем на буфер данных и количеством байт. За¬ 
тем управление передается операционной системе, вызывающей подходя¬ 
щий драйвер. Предположим, что драйвер работает с диском и прекращает 
свое действие до тех пор, пока не произойдет прерывание. В случае чтения 
данных с диска, очевидно, вызывающая программа должна быть заблокиро¬ 
вана (потому что для нее нет данных). Что происходит при записи данных 
на диск? Нужно ли блокировать вызывающую программу для ожидания за¬ 
вершения передачи данных на диск? 

14. В чем заключается разница между эмулированным и аппаратным прерыва¬ 
ниями? 

15. Компьютер использует схему настройки адресов программы, показанную 
на рис. 1.9, а. Программа длиной в 10 000 байт загружена по адресу 40 000. 
Какие значения примут базовый и предельный регистры соответственно 
схеме, описанной в тексте? 
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16. Почему в системах разделения времени необходима таблица процессов? 
Нужна ли она также в системах на персональных компьютерах, где суще¬ 
ствует только один процесс, и этот процесс завладевает всей машиной до тех 
пор, пока не завершится? 

17. Есть ли какая-нибудь причина, по которой вам может понадобиться встро¬ 
ить файловую систему в непустой каталог? Если да, то что это за причина? 

18. Для каждого из следующих системных вызовов укажите условие, при кото¬ 
ром возникнет ошибка: Еогк, ехес и ипііпк. 

19. Может ли вызов 

соипТ = мгіЕеСЕсі. ЬиЕЕег, пЬуЕез): 

вернуть в переменной соипС величину, отличную от пЪуіез ? Если да, то почему? 

20. Файл, дескриптором которого является /й?, содержит следующую последо¬ 
вательность байтов: 3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5. Выполняется следующий сис¬ 
темный вызов: 

І5еек(Гс1. 3, 5ЕЕК_5ЕТ): 
геасКЕсІ. &Ьи1Тег. 4): 

где вызов Ізеек ищет байт 3 в файле. Что будет содержать буфер после за¬ 
вершения операции чтения? 

21. В чем заключается существенная разница между блоковым специальным 
файлом и символьным специальным файлом? 

22. В примере, показанном на рис. 1,17, библиотечная процедура имеет назва¬ 
ние гесмі, и сам системный вызов называется геаб. Существенно ли то, что 
они имеют одинаковые имена? Если нет, то которое важнее? 

23. Модель клиент-сервер популярна в распределенных системах. Можно ли ее 
также использовать в однокомпьютерных системах? 

24. Для программиста системный вызов выглядит так же, как и любой другой 
вызов библиотечной процедуры. Должен ли программист знать, обращение 
к каким библиотечным процедурам приводит в результате к системным вы¬ 
зовам? При каких условиях и почему? 

25. В табл. 1.2 показано, что ряд системных вызовов ІЖІХ не имеют эквива¬ 
лентов в \Уіп32 АРІ. Каковы последствия для программиста перевода про¬ 
граммы ІЖІХ для запуска под\Уіпс1о\ѵ5 (для каждого из вызовов, помечен¬ 
ных, как не имеющие эквивалента)? 

26. Несколько задач для тренировки перевода одних единиц в другие: 

а) сколько длится микрогод в секундах? 

б) микрометры часто называют микронами. Какова длина гигамикрона? 

в) сколько байт в памяти размером в 1 Тбайт? 

г) масса земли составляет 6000 йоттаграмм. Какова она в килограммах? 

27. Напишите оболочку, похожую на представленную в листинге 1.1, но содер¬ 
жащую все необходимое для того, чтобы она работала, так что вы смогли бы 
ее протестировать. Вы можете также добавить некоторые элементы, напри¬ 
мер перенаправление ввода и вывода, каналы и фоновые задания. 
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28. Если у вас есть персональная система из семейства ІЛЧІХ (Ілпих, МІШХ, 
Ргее В5В и т. д.), которую вам не страшно «повесить» и перезагрузиться, 
напишите сценарий для оболочки, который пытается создать неограничен¬ 
ное число дочерних процессов, запустите его и посмотрите, что произойдет. 
Перед запуском эксперимента наберите команду зупс, чтобы сбросить на 
диск содержимое буферов файловой системы во избежание крушения фай¬ 
ловой системы. Замечание: не пытайтесь сделать это на разделенной системе 
без предварительного получения разрешения от системного администрато¬ 
ра. Последствия этой операции проявятся немедленно, поэтому вас, скорее 
всего, поймают и применят к вам соответствующие санкции. 

29. Исследуйте и попытайтесь интерпретировать содержимое каталогов в сис¬ 
темах семейства ИЫІХ или \Уіпс1о\ѵ5 с помощью программ осі системы ІЖІХ 
или БЕВІЮ в М8-В05. Совет, то, как вы это сделаете, зависит от того, что 
позволяет операционная система. Есть одна уловка, которая может сработать: 
создайте каталог на гибком диске в одной операционной системе, а затем 
считайте необработанные данные диска, используя другую операционную 
систему, которая позволяет подобный доступ. 




Глава 2 

Процессы и потоки 


Теперь мы детально рассмотрим устройство и работу операционных систем. Основ¬ 
ным понятием, связанным с операционными системами, является процесс — абст¬ 
рактное понятие, описывающее работу программы. Все остальное базируется на 
этом понятии, поэтому представляется крайне важным, чтобы разработчики опера¬ 
ционных систем (а также студенты) получили полное представление о концепции 
процесса как можно раньше. 


Процессы 

Все современные компьютеры могут делать одновременно несколько дел. Напри¬ 
мер, одновременно с запущенной пользователем программой может выполняться 
чтение с диска и вывод текста на экран монитора или на принтер. В многозадач¬ 
ной системе процессор переключается между программами, предоставляя каждой 
от десятков до сотен миллисекунд. При этом в каждый конкретный момент време¬ 
ни процессор занят только одной программой, но за секунду он успевает поработать 
с несколькими программами, создавая у пользователей иллюзию параллельной 
работы со всеми программами. Иногда в этом контексте говорят о псевдопарал¬ 
лелизме, в отличие от настоящего параллелизма в многопроцессорных системах 
(в которых установлено два и более процессора, разделяющих между собой общую 
физическую память). Следить за работой параллельно идущих процессов достаточ¬ 
но трудно, поэтому со временем разработчики операционных систем разработали 
концептуальную модель последовательных процессов, упрощающую эту работу. 
Темой данной главы будет содержание и применение этой модели, а также неко¬ 
торые результаты ее применения. 

Модель процесса 

В этой модели все функционирующее на компьютере программное обеспечение, 
иногда включая собственно операционную систему, организовано в виде набора 
последовательных процессов, или, для краткости, просто процессов. Процессом 
является выполняемая программа, включая текущие значения счетчика команд, 
регистров и переменных. С позиций данной абстрактной модели, у каждого процес¬ 
са есть собственный виртуальный центральный процессор. На самом деле, разуме¬ 
ется, реальный процессор переключается с процесса на процесс, но для лучшего 
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понимания системы значительно проще рассматривать набор процессов, идущих 
параллельно (псевдопараллельно), чем пытаться представить себе процессор, пере¬ 
ключающийся от программы к программе. Как мы уже знаем из первой главы, это 
переключение и называется многозадачностью или мультипрограммированием. 

На рис. 2.1, а представлена схема компьютера, работающего с четырьмя про¬ 
граммами. На рис. 2.1, б представлены четыре процесса, каждый со своей управ¬ 
ляющей логикой (то есть логическим счетчиком команд), идущие независимо друг 
от друга. Разумеется, на самом деле существует только один физический счетчик 
команд, в который загружается логический счетчик команд текущего процесса. 
Когда время, отведенное текущему процессу, заканчивается, физический счетчик 
команд сохраняется в логическом счетчике команд процесса в памяти. На рис. 2.1, в 
видно, что за достаточно большой промежуток времени изменилось состояние всех 
четырех процессов, но в каждый конкретный момент в действительности работает 
только один процесс. 


Один счетчик команд 
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Рис. 2.1. Четыре программы в многозадачном режиме (а); принципиальная модель четырех 
независимых последовательных процессов (б); в каждый момент времени активна 
только одна программа (в) 


Поскольку процессор переключается между программами, скорость, с которой 
процессор производит свои вычисления, будет непостоянной и, возможно, даже 
будет отличной при каждом новом запуске процесса. Поэтому не следует про¬ 
граммировать процессы, исходя из каких-либо жестко заданных временных пред¬ 
положений. Представьте себе, например, процесс ввода-вывода, запускающий 
накопитель на магнитной ленте для восстановления заархивированных файлов. 
Процесс выполняет холостой цикл задержки 10 000 раз, чтобы дать время накопи¬ 
телю разогнаться, а затем дает команду считать первый сектор. Если во время хо¬ 
лостого цикла процессор решит переключиться на другую задачу, может случить¬ 
ся так, что работающий с магнитофоном процесс запустится снова уже после того, 
как считывающая головка пройдет первую запись. Если у процесса есть критичес¬ 
кие временные рамки такого рода, то есть отдельные события должны укладывать¬ 
ся в заданное количество миллисекунд, необходимы специальные меры, чтобы 
удостовериться в завершенности события. Однако обычно многозадачный режим 
процессора, а также относительные скорости различных процессов не влияют на 
работу большинства процессов. 

Различие между процессом и программой трудноуловимо и тем не менее име¬ 
ет принципиальное значение. Воспользуемся следующей аналогией: представьте 




Процессы 


99 


себе программиста, разбирающегося в кулинарии и пекущего торт на день рожде¬ 
ния своей дочери. В его распоряжении есть рецепт торта, кухня, оборудованная 
всем необходимым, и ингредиенты для торта: мука, яйца, сахар, ванилин и т. п. 
Согласно этой аналогии, рецепт — это программа (то есть алгоритм, записанный 
в заданном виде), программист исполняет роль процессора, а ингредиенты торта 
являются входными данными. Процессом является следующая последователь¬ 
ность действий: программист читает рецепт, смешивает продукты и печет торт. 

Теперь представьте, что на кухню прибегает плачущий сын программиста и кри¬ 
чит, что его ужалила пчела. Программист отмечает, на чем он остановился (сохра¬ 
няет текущее состояние процесса), находит справочник по оказанию первой по¬ 
мощи и действует в соответствии с инструкцией. Таким образом, наш процессор 
переключился с одного процесса (выпечка торта) на другой, с большим приорите¬ 
том (оказание первой помощи), и у каждого процесса есть своя программа (рецепт 
торта и справочник по оказанию первой помощи). После проведения всех необхо¬ 
димых процедур по борьбе с укусом пчелы программист возвращается к торту, 
продолжая с той операции, на которой он прервался. 

Мы привели эту аналогию с целью показать, что процесс — это активность не¬ 
которого рода. У него есть программа, входные и выходные данные, а также состо¬ 
яние. Один процессор может переключаться между различными процессами, ис¬ 
пользуя некий алгоритм планирования для определения момента переключения 
от одного процесса к другому. 

Создание процесса 

Операционной системе необходим способ, позволяющий удостовериться в нали¬ 
чии всех необходимых процессов. В простейших системах, а также системах, раз¬ 
работанных для выполнения одного-единственного приложения (например, кон¬ 
троллер микроволновой печи), можно реализовать такую ситуацию, в которой все 
процессы, которые когда-либо могут понадобиться, присутствуют в системе при 
ее загрузке. В универсальных системах необходим способ создания и прерывания 
процессов по мере необходимости. В этом разделе мы рассмотрим некоторые из 
возможных способов решения этой проблемы. Ниже перечислены четыре основ¬ 
ных события, приводящие к созданию процессов. 

1. Инициализация системы. 

2. Выполнение изданного работающим процессом системного запроса на созда¬ 
ние процесса. 

3. Запрос пользователя на создание процесса. 

4. Инициирование пакетного задания. 

Обычно при загрузке операционной системы создаются несколько процессов. 
Некоторые из них являются высокоприоритетными процессами, то есть обес¬ 
печивающими взаимодействие с пользователем и выполняющими заданную ра¬ 
боту. Остальные процессы являются фоновыми, они не связаны с конкретными 
пользователями, но выполняют особые функции. Например, один фоновый про¬ 
цесс может быть предназначен для обработки приходящей на компьютер почты, 
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активизируясь только по мере появления писем. Другой фоновый процесс может 
обрабатывать запросы к \ѵеЬ-страницам, расположенным на компьютере, и акти¬ 
визироваться для обслуживания полученного запроса. Фоновые процессы, связан¬ 
ные с электронной почтой, \ѵеЬ-страницами, новостями, выводом на печать и т. п., 
называются демонами. В больших системах насчитываются десятки демонов. 
В ИШХ для вывода списка запущенных процессов используется программа рз. 
В \Уіпс1о\ѵ5 95/98/Ме достаточно нажать СТЖ-АП-ОЕЦ а в \Ѵіпс1о\ѵз 2000 можно вос¬ 
пользоваться диспетчером задач, вызываемым этой же комбинацией трех клавиш. 

Процессы могут создаваться не только в момент загрузки системы, но и позже. 
Например, новый процесс (или несколько) может быть создан по просьбе текуще¬ 
го процесса. Создание новых процессов особенно полезно в тех случаях, когда вы¬ 
полняемую задачу проще всего сформировать как набор связанных, но тем не ме¬ 
нее независимых взаимодействующих процессов. Если необходимо организовать 
выборку большого количества данных из сети для дальнейшей обработки, удобно 
создать один процесс для выборки данных и размещения их в совместно исполь¬ 
зуемом буфере, в то время как второй процесс будет считывать данные из буфера 
и обрабатывать их. Эта схема даже ускорит обработку данных, если каждый про¬ 
цесс запустить на отдельном процессоре в случае многопроцессорной системы. 

В интерактивных системах пользователь может запустить программу, набрав 
на клавиатуре команду или дважды щелкнув на значке программы. В обоих случаях 
результатом будет создание нового процесса и запуск в нем программы. Когда на 
ІЖІХ работает X \УтсІо\ѵ5, новый процесс получает то окно, в котором был запу¬ 
щен. В МісгозоЙ; \Уіпс1о\ѵ5 процесс не имеет собственного окна при запуске, но он 
может (и должен) создать одно или несколько окон. В обеих системах пользователь 
может одновременно открыть несколько окон, каждому иэ которых соответствует 
свой процесс. Пользователь может переключаться между окнами с помощью мыши 
и взаимодействовать с процессом, например, вводя данные по мере необходимости. 

Последнее событие, приводящее к созданию нового процесса, связано с система¬ 
ми пакетной обработки на больших компьютерах. Пользователи посылают пакет¬ 
ное задание (возможно, с использованием удаленного доступа), а операционная 
система создает новый процесс и запускает следующее задание из очереди в тот 
момент, когда освобождаются необходимые ресурсы. 

С технической точки зрения во всех перечисленных случаях новый процесс 
формируется одинаково: текущий процесс выполняет системный запрос на созда¬ 
ние нового процесса. В роли текущего процесса может выступать процесс, запущен¬ 
ный пользователем, системный процесс, инициированный клавиатурой или мышью, 
а также процесс, управляющий пакетами. В любом случае этот процесс всего лишь 
выполняет системный запрос и создает новый процесс. Системный запрос застав¬ 
ляет операционную систему создать новый процесс, а также прямо или косвенно 
содержит информацию о программе, которую нужно запустить в этом процессе. 

В ІЖІХ существует только один системный запрос, направленный на создание 
нового процесса: Гогк {ветвление или вилка). Этот запрос создает дубликат вызы¬ 
ваемого процесса. После выполнения запроса Тогк двум процессам — родитель¬ 
скому и дочернему — соответствуют одинаковые образы памяти, строки окружения 
и одни и те же открытые файлы. Обычно дочерний процесс выполняет системный 
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вызов ехесѵе (или похожий) для изменения своего образа памяти и запуска новой 
программы. Так, когда пользователь набирает на клавиатуре команду $огі , оболоч¬ 
ка создает путем ветвления дочерний процесс, который и выполняет программу 
$огі. Смысл этого двухступенчатого процесса заключается в том, что дочерний про¬ 
цесс успевает обработать описания файлов после Тогк, но до ехесѵе, чтобы выпол¬ 
нить перенаправление стандартных устройств ввода и вывода и потока сообще¬ 
ний об ошибках. 

В \Уіпс1о\Ѵ5 же вызов всего одной функции СгеаІеРгосезз интерфейса "\Ѵт32 
управляет и созданием процесса, и запуском в нем нужной программы. У этой 
функции 10 параметров: программа, которую нужно запустить, параметры команд¬ 
ной строки этой программы, различные атрибуты защиты, биты, управляющие 
наследованием открытых файлов, приоритеты, спецификация окна, которое сле¬ 
дует открыть для процесса, и указатель на структуру, в которой информация о со¬ 
зданном процессе возвращается вызывающей программе. Кроме СгеаѣеРгосезз в 
"\Уіп32 есть около 100 функций для управления процессами и их синхронизации. 

И в ІЛЧІХ, и в \Уіпс1о\ѵ5 после создания нового процесса родительский и дочер¬ 
ний процессы имеют собственные различные адресные пространства. При изме¬ 
нении любым процессом слова в адресном пространстве это изменение незаметно 
для других процессов. В ІЖІХ начальное адресное пространство дочернего про¬ 
цесса является копией родительского, но сами адресные пространства различны, 
и перезаписываемая память совместно не используется (некоторые приложения 
ІЖІХ совместно используют текст программы, поскольку его нельзя модифи¬ 
цировать). В то же время созданный процесс может использовать совместно с 
родительским процессом некоторые другие ресурсы, например открытые файлы. 
В \Ѵіп(іо\Ѵ5 адресные пространства родительского и дочернего процессов отлича¬ 
ются с самого начала. 

Завершение процесса 

После того как процесс создан, он начинает выполнять свою работу. Но ничто не 
длится вечно, даже процесс — рано или поздно он завершится, чаще всего благо¬ 
даря одному из следующих событий: 

1. Обычный выход (преднамеренно). 

2. Выход по ошибке (преднамеренно). 

3. Выход по неисправимой ошибке (непреднамеренно). 

4. Уничтожение другим процессом (непреднамеренно). 

В основном процессы завершаются по мере выполнения своей работы. После 
окончания компиляции программы компилятор выполняет системный запрос, 
чтобы сообщить операционной системе об окончании работы. В ІШІХ этот сис¬ 
темный запрос — ехИ, а в \Ѵіп(іо\ѵ5 — ЕхііРгосезз. Программы, рассчитанные на 
работу с экраном, также поддерживают преднамеренное завершение. В текстовых 
редакторах, браузерах и других программах такого типа обычно есть кнопка или 
пункт меню, щелкнув на котором можно удалить все временные файлы, открытые 
процессом, и затем завершить процесс. 
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Второй причиной завершения процесса может стать неустранимая ошибка. 
Например, если пользователь набрал на клавиатуре команду 

сс Гоо.с 

для компиляции программы /оо.с, а соответствующего файла не существует, 
компилятор просто закончит работу. Интерактивные процессы, рассчитанные на 
работу с экраном, обычно не завершают работу при получении неверных парамет¬ 
ров, вместо этого выводя на экран диалоговое окно и прося пользователя ввести 
правильные параметры. 

Третьей причиной завершения процесса является ошибка, вызванная самим 
процессом, чаще всего связанная с ошибкой в программе. В качестве примера мож¬ 
но привести выполнение недопустимой команды, обращение к несуществующей 
области памяти и деление на ноль. В некоторых системах (например, в ІЖІХ) про¬ 
цесс может информировать операционную систему о том, что он сам обработает 
некоторые ошибки, и в этом случае процессу посылается сигнал (процесс преры¬ 
вается, а не завершается) при появлении ошибки. 

Четвертой причиной завершения процесса может служить выполнение другим 
процессом системного запроса на уничтожение процесса. В ІЖІХ такой системный 
запрос — кіП, а соответствующая функция \Ѵіп32 — ТегшіпаѣеРгосезз. В обоих слу¬ 
чаях «киллер» должен обладать соответствующими полномочиями по отношению 
к «убиваемому» процессу. В некоторых системах при завершении процесса (пред¬ 
намеренно или нет) все процессы, созданные процессом, также завершаются. Впро¬ 
чем, это не относится ни к ІМІХ, ни к \Ѵіпс1о\ѵ5. 

Иерархия процессов 

В некоторых системах родительский и дочерний процессы остаются связанными 
между собой определенным образом. Дочерний процесс также может, в свою оче¬ 
редь, создавать процессы, формируя иерархию процессов. Следует отметить, что 
в отличие от животного мира у процесса может быть лишь один родитель и сколько 
угодно «детей». 

В ІЖІХ процесс, все его «дети» и дальнейшие потомки образуют группу про¬ 
цессов. Сигнал, посылаемый пользователем с клавиатуры, доставляется всем чле¬ 
нам группы, взаимодействующим с клавиатурой в данный момент (обычно это все 
активные процессы, созданные в текущем окне). Каждый из процессов может пе¬ 
рехватить сигнал, игнорировать его или выполнить другое действие, предусмот¬ 
ренное по умолчанию. 

Рассмотрим в качестве еще одного примера иерархии процессов инициализа¬ 
цию ІЛѴІХ при запуске. В образе загрузки присутствует специальный процесс ітС. 
При запуске этот процесс считывает файл, в котором находится информация о 
количестве терминалов. Затем процесс разветвляется таким образом, чтобы каж¬ 
дому терминалу соответствовал один процесс. Процессы ждут, пока какой-нибудь 
пользователь не войдет в систему. Если пароль правильный, процесс входа в систе¬ 
му запускает оболочку для обработки команд пользователя, которые, в свою очередь, 
могут запускать процессы. Таким образом, все процессы в системе принадлежат к 
единому дереву, начинающемуся с процесса іпі(. Напротив, в \Ѵіп(1о\ѵ5 не суще- 
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ствует понятия иерархии процессов, и все процессы равноправны. Единственное, 
в чем проявляется что-то вроде иерархии процессов — создание процесса, в кото¬ 
ром родительский процесс получает специальный маркер (так называемый деск¬ 
риптор), позволяющий контролировать дочерний процесс. Но маркер можно пе¬ 
редать другому процессу, нарушая иерархию. В ІЖІХ это невозможно. 


Состояния процессов 

Несмотря на то что процесс является независимым объектом, со своим счетчиком 
команд и внутренним состоянием, существует необходимость взаимодействия с 
другими процессами. Например, выходные данные одного процесса могут служить 
входными данными для другого процесса. В команде оболочки 

саТ сІіарТегІ сЬарТег2 сЬаріегЗ | дгер ігее 

первый процесс, исполняющий файл саѣ, объединяет и выводит три файла. Вто¬ 
рой процесс, исполняющий файл дгер, отбирает все строки, содержащие слово 
«Нее». В зависимости от относительных скоростей процессов (скорости зависят 
от относительной сложности программ и процессорного времени, предоставляе¬ 
мого каждому процессу), может получиться, что дгер уже готов к запуску, но вход¬ 
ных данных для этого процесса еще нет. В этом случае процесс блокируется до 
поступления входных данных. 

Процесс блокируется, поскольку с точки зрения логики он не может продол¬ 
жать свою работу (обычно это связано с отсутствием входных данных, ожидаемых 
процессом). Также возможна ситуация, когда процесс, готовый и способный рабо¬ 
тать, останавливается, поскольку операционная система решила предоставить на 
время процессор другому процессу. Эти ситуации являются принципиально раз¬ 
ными. В первом случае приостановка выполнения является внутренней пробле¬ 
мой (поскольку невозможно обработать командную строку пользователя до того, 
как она была введена). Во втором случае проблема является технической (нехват¬ 
ка процессоров для каждого процесса). На рис. 2.2 представлена диаграмма состо¬ 
яний, показывающая три возможных состояния процесса: 

1. Работающий (в этот конкретный момент использующий процессор). 

2. Готовый к работе (процесс временно приостановлен, чтобы позволить вы¬ 
полняться другому процессу). 

3. Заблокированный (процесс не может быть запущен прежде, чем произой¬ 
дет некое внешнее событие). 



1. Процесс блокируется, ожидая входных данных 

2. Планировщик выбирает другой процесс 

3. Планировщик выбирает этот процесс 

4. Доступны входные данные 


Рис. 2.2. Процесс может находиться в рабочем, готовом и заблокированном состоянии. 
Стрелками показаны возможные переходы между состояниями 
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С точки зрения логики первые два состояния одинаковы. В обоих случаях про¬ 
цесс может быть запущен, только во втором случае недоступен процессор. Третье 
состояние отличается тем, что запустить процесс невозможно, независимо от за¬ 
груженности процессора. 

Как показано на рис. 2.2, между этими тремя состояниями возможны четыре 
перехода. Переход 1 происходит, когда процесс обнаруживает, что продолжение 
работы невозможно. В некоторых системах процесс должен выполнить системный 
запрос, например Ы оск или раизе, чтобы оказаться в заблокированном состоянии. 
В других системах, как в ІЖІХ, процесс автоматически блокируется, если при счи¬ 
тывании из канала или специального файла (предположим, терминала) входные 
данные не были обнаружены. 

Переходы 2 и 3 вызываются частью операционной системы, называемой пла¬ 
нировщиком процессов, так что сами процессы даже не знают о существовании 
этих переходов. Переход 2 происходит, если планировщик решил, что пора предо¬ 
ставить процессор следующему процессу. Переход 3 происходит, когда все осталь¬ 
ные процессы уже исчерпали свое процессорное время, и процессор снова воз¬ 
вращается к первому процессу. Вопрос планирования (когда следует запустить 
очередной процесс и на какое время) сам по себе достаточно важен, и мы вернемся 
к нему позже в этой главе. Было разработано множество алгоритмов с целью сба¬ 
лансировать требования эффективности для системы в целом и для каждого про¬ 
цесса в отдельности. Мы также рассмотрим некоторые из них ниже в этой главе. 

Переход 4 происходит с появлением внешнего события, ожидавшегося про¬ 
цессом (например, прибытие входных данных). Если в этот момент не запущен 
какой-либо другой процесс, то срабатывает переход.?, и процесс запускается. 
В противном случае процессу придется некоторое время находиться в состоянии 
готовности, пока не освободится процессор. 

Модель процессов упрощает представление о внутреннем поведении системы. 
Некоторые процессы запускают программы, выполняющие команды, введенные с 
клавиатуры пользователем. Другие процессы являются частью системы и обраба¬ 
тывают такие задачи, как выполнение запросов файловой службы, управление за¬ 
пуском диска или магнитного накопителя. В случае дискового прерывания систе¬ 
ма останавливает текущий процесс и запускает дисковый процесс, который был 
заблокирован в ожидании этого прерывания. Вместо прерываний мы можем пред¬ 
ставлять себе дисковые процессы, процессы пользователя, терминала и т. п., бло¬ 
кирующиеся на время ожидания событий. Когда событие произошло (информа¬ 
ция прочитана с диска или клавиатуры), блокировка снимается и процесс может 
быть запущен. 

Рассмотренный подход описывается моделью, представленной на рис. 2.3. 
Нижний уровень операционной системы — это планировщик, на верхних уровнях 
расположено множество процессов. Вся обработка прерываний и детали, связан¬ 
ные с остановкой и запуском процессов, спрятаны в том, что мы назвали плани¬ 
ровщиком, являющимся, по сути, совсем небольшой программой. Вся остальная 
часть операционной системы удобно структурирована в виде набора процессов. 
Очень немногие существующие системы структурированы столь удобно. 
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Рис. 2.3. Нижний уровень операционной системы отвечает за прерывания и планирование. 

Выше расположены последовательные процессы 

Реализация процессов 

Для реализации модели процессов операционная система содержит таблицу (мас¬ 
сив структур), называемую таблицей процессов, с одним элементом для каждого 
процесса. (Некоторые авторы называют эти элементы блоками управления про¬ 
цессом.) Элемент таблицы содержит информацию о состоянии процесса, счетчи¬ 
ке команд, указателе стека, распределении памяти, состоянии открытых файлов, 
об использовании и распределении ресурсов, а также всю остальную информацию, 
которую необходимо сохранять при переключении в состояние готовности или 
блокировки для последующего запуска — как если бы процесс не останавливался. 

В табл. 2.1 представлены некоторые наиболее важные поля типичной системы. 
Поля в первой колонке относятся к управлению процессом. Остальные колонки 
описывают управление памятью и файлами. Необходимо отметить, что от конк¬ 
ретной системы очень сильно зависит, какие именно поля будут в таблице процес¬ 
сов, но табл. 2.1 дает общее представление о необходимой информации. 

Теперь, после знакомства с таблицей процессов, можно сказать еще несколько 
слов о том, как поддерживается иллюзия нескольких последовательных процес¬ 
сов на машине с одним процессором и несколькими устройствами ввода-вывода. 
С каждым классом устройств ввода-вывода (гибкий диск, жесткий диск, таймер, 
терминал) связана область памяти (обычно расположенная в нижних адресах), 
называемая вектором прерываний. Вектор прерываний содержит адрес процеду¬ 
ры обработки прерываний. Представьте, что в момент прерывания диска работал 
пользовательский процесс 3. Содержимое счетчика команд процесса, слово состоя¬ 
ния программы и, возможно, один или несколько регистров записываются в (теку¬ 
щий) стек аппаратными средствами прерывания. Затем происходит переход по 
адресу, указанному в векторе прерывания диска. Вот и все, что делают аппарат¬ 
ные средства прерывания. С этого момента вся остальная обработка прерывания 
производится программным обеспечением, например процедурой обработки пре¬ 
рываний. 

Все прерывания начинаются с сохранения регистров, часто в блоке управления 
текущим процессом в таблице процессов. Затем информация, помещенная в стек 
прерыванием, удаляется, и указатель стека переставляется на временный стек, ис¬ 
пользуемый программой обработки процесса. Такие действия, как сохранение ре¬ 
гистров и установка указателя стека, невозможно даже выразить на языке высоко¬ 
го уровня (например, на С). Поэтому они выполняются небольшой программой 
на ассемблере, обычно одинаковой для всех прерываний, поскольку процедура 
сохранения регистров не зависит от причины возникновения прерывания. 
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Таблица 2.1. Некоторые поля типичного элемента таблицы процессов 


Управление процессом Управление памятью Управление файлами 


Регистры 
Счетчик команд 
Слово состояния программы 
Указатель стека 

Состояние процесса 
Приоритет 

Параметры планирования 
Идентификатор процесса 
Родительский процесс 
Группа процесса 
Сигналы 

Время начала процесса 
Использованное процессорное время 
Процессорное время дочернего процесса 
Время следующего аварийного сигнала 


Указатель на текстовый сегмент 
Указатель на сегмент данных 
Указатель на сегмент стека 


Корневой каталог 
Рабочий каталог 
Дескрипторы файла 
Идентификатор 
пользователя 
Идентификатор группы 


По завершении своей работы эта программа вызывает процедуру на языке С, 
которая выполняет все остальные действия, связанные с конкретным прерыванием. 
(Мы предполагаем, что операционная система написана на С, что является стандарт¬ 
ным решением для всех существующих операционных систем.) Когда процедура 
завершает свою работу (в результате чего, возможно, некоторые процессы переходят 
в состояние готовности), вызывается планировщик для выбора следующего процес¬ 
са. После этого управление возвращается к программе на ассемблере, загружающей 
регистры и карту памяти для текущего процесса и запускающей его. Управление 
прерыванием и работа планировщика представлены в табл. 2.2. Следует отметить, 
что отдельные детали могут несколько варьироваться от системы к системе. 

Таблица 2.2. Схема обработки прерывания нижним уровнем операционной системы 

1. Аппаратное обеспечение сохраняет в стеке счетчик команд и т. п. 

2. Аппаратное обеспечение загружает новый счетчик команд из вектора прерываний 

3. Процедура на ассемблере сохраняет регистры 

4. Процедура на ассемблере устанавливает новый стек 

5. Запускается программа обработки прерываний на С. (Она обычно считывает 
и буферизирует входные данные) 

6. Планировщик выбирает следующий процесс 

7. Программа на С передает управление процедуре на ассемблере 

8. Процедура на ассемблере запускает новый процесс 


Потоки 

В обычных операционных системах каждому процессу соответствует адресное 
пространство и одиночный управляющий поток. Фактически это и определяет 
процесс. Тем не менее часто встречаются ситуации, в которых предпочтительно 
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иметь несколько квазипараллельных управляющих потоков в одном адресном про¬ 
странстве, как если бы они были различными процессами (однако разделяющим 
одно адресное пространство). В следующих разделах мы рассмотрим такие ситуации. 

Модель потока 

Модель процесса, которую мы рассматривали, базируется на двух независимых 
концепциях: группировании ресурсов и выполнении программы. Иногда полезно 
их разделять, и тут появляется понятие потока. 

С одной стороны, процесс можно рассматривать как способ объединения род¬ 
ственных ресурсов в одну группу. У процесса есть адресное пространство, содер¬ 
жащее текст программы и данные, а также другие ресурсы. Ресурсами являются 
открытые файлы, дочерние процессы, необработанные аварийные сообщения, об¬ 
работчики сигналов, учетная информация и многое другое. Гораздо проще управ¬ 
лять ресурсами, объединив их в форме процесса. 

С другой стороны, процесс можно рассматривать как поток исполняемых ко¬ 
манд или просто поток. У потока есть счетчик команд, отслеживающий порядок 
выполнения действий. У него есть регистры, в которых хранятся текущие пере¬ 
менные. У него есть стек, содержащий протокол выполнения процесса, где на каж¬ 
дую процедуру, вызванную, но еще не вернувшуюся, отведен отдельный фрейм. 
Хотя поток должен исполняться внутри процесса, следует различать концепции 
потока и процесса. Процессы используются для группирования ресурсов, а потоки 
являются объектами, поочередно исполняющимися на центральном процессоре. 

Концепция потоков добавляет к модели процесса возможность одновременно¬ 
го выполнения в одной и той же среде процесса нескольких программ, в достаточ¬ 
ной степени независимых. Несколько потоков, работающих параллельно в одном 
процессе, аналогичны нескольким процессам, идущим параллельно на одном компь¬ 
ютере. В первом случае потоки разделяют адресное пространство, открытые файлы 
и другие ресурсы. Во втором случае процессы совместно пользуются физической 
памятью, дисками, принтерами и другими ресурсами. Потоки обладают некоторы¬ 
ми свойствами процессов, поэтому их иногда называют упрощенными процесса¬ 
ми. Термин многопоточность также используется для описания использования 
нескольких потоков в одном процессе. 

На рис. 2.4, а представлены три обычных процесса, у каждого из которых есть 
собственное адресное пространство и одиночный поток управления. На рис. 2.4, б 
представлен один процесс с тремя потоками управления. В обоих случаях мы име¬ 
ем три потока, но на рис. 2.4, а каждый из них имеет собственное адресное про¬ 
странство, а на рис. 2.4, б потоки разделяют единое адресное пространство. 

При запуске многопоточного процесса в системе с одним процессором потоки 
работают поочередно. Пример работы процессов в многозадачном режиме мы уже 
видели на рис. 2.1. Иллюзия параллельной работы нескольких различных по¬ 
следовательных процессов создается путем постоянного переключения системы 
между процессами. Многопоточность реализуется примерно так же. Процессор 
быстро переключается между потоками, создавая впечатление параллельной 
работы потоков, хотя и на не столь быстром процессоре. В случае трех ограни¬ 
ченных производительностью процессора потоков в одном процессе все потоки 
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будут работать параллельно, и каждому потоку будет соответствовать виртуаль¬ 
ный процессор с быстродействием, равным одной трети быстродействия реаль¬ 
ного процессора. 

Процесс 1 Процесс 1 Процесс 1 Процесс 




Рис. 2.4. Три процесса с одиночными потоками управления (а); один процесс с тремя 

потоками управления (б) 

Различные потоки в одном процессе не так независимы, как различные процес¬ 
сы. У всех потоков одно и то же адресное пространство, что означает совместное 
использование глобальных переменных. Поскольку любой поток имеет доступ к 
любому адресу ячейки памяти в адресном пространстве процесса, один поток мо¬ 
жет считывать, записывать или даже стирать информацию из стека другого пото¬ 
ка. Защиты не существует, поскольку (1) это невозможно и (2) это ненужно. В от¬ 
личие от различных процессов, которые могут быть инициированы различными 
пользователями и преследовать несовместимые цели, один процесс всегда запу¬ 
щен одним пользователем, и потоки созданы таким образом, чтобы работать со¬ 
вместно, не мешая друг другу. Как показано в табл. 2.3, потоки разделяют не толь¬ 
ко адресное пространство, но и открытые файлы, дочерние процессы, сигналы 
и т. и. Таким образом, ситуацию на рис. 2.4, а следует использовать в случае абсо¬ 
лютно несвязанных процессов, тогда как схема на рис. 2.4, б будет уместна, когда 
потоки выполняют совместно одну работу. 

Таблица 2.3. В первой колонке перечислены элементы, совместно используемые 
всеми потоками процесса, а во второй — элементы, индивидуальные 
для каждого потока 

Элементы процесса Элементы потока 

Адресное пространство Счетчик команд 

Глобальные переменные Регистры 

Открытые файлы Стек 

Дочерние процессы Состояние 

Необработанные аварийные сигналы 

Сигналы и их обработчики 

Информация об использовании ресурсов 
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Первая колонка содержит элементы, являющиеся свойствами процесса, а не 
потока. Например, если один поток открывает файл, этот файл тут же становится 
видимым для остальных потоков, и они могут считывать информацию и записы¬ 
вать ее в файл. Это логично, поскольку процесс, а не поток является единицей 
управления ресурсами. Если бы у каждого потока было собственное адресное про¬ 
странство, открытые файлы, аварийные сигналы, требующие обработки и т. д„ это 
были бы отдельные процессы. Концепция потоков состоит в возможности совмест¬ 
ного использования набора ресурсов несколькими потоками для выполнения не¬ 
кой задачи в тесном взаимодействии. 

Как и любой обычный процесс (то есть процесс с одним потоком), поток может 
находиться в одном из нескольких состояний: рабочем, заблокированном, готов¬ 
ности или завершенном. Действующий поток взаимодействует с процессором. 
Блокированный поток ожидает некоторого события, которое его разблокирует. 
Например, при выполнении системного запроса чтения с клавиатуры поток бло¬ 
кируется, пока не поступит сигнал с клавиатуры. Поток может быть разблокиро¬ 
ван каким-либо внешним событием или другим потоком. Поток в состоянии 
готовности будет запущен, как только до него дойдет очередь. Переходы между со¬ 
стояниями потоков такие же, как на рис. 2.2. 

Важно понимать, что у каждого потока свой собственный стек, как показано на 
рис. 2.5. Стек каждого потока содержит по одному фрейму для каждой процеду¬ 
ры, вызванной, но еще не вернувшей управления. Во фрейме находятся локаль¬ 
ные переменные процедуры и адрес возврата. Например, если процедура X вызы¬ 
вает процедуру У и она, в свою очередь, вызывает процедуру 2, то во время работы 
процедуры 2 в стеке будут находиться фреймы для всех трех процедур. Каждый 
поток может вызывать различные процедуры и, соответственно, иметь различный 
протокол выполнения процесса — именно поэтому каждому потоку необходим 
собственный стек. 



Рис. 2.5. У каждого потока свой собственный стек 


В многопоточном режиме процессы, как правило, запускаются с одним пото¬ 
ком. Этот поток может создавать новые потоки, вызывая библиотечную процеду¬ 
ру, например ікгеа(і_сгеаіе. Параметром обычно является имя процедуры, кото- 
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рую необходимо запустить для создания нового потока. Указание какой-либо ин¬ 
формации, касающейся адресного пространства нового потока, не является необ¬ 
ходимым (или даже возможным), поскольку новый поток создается в адресном 
пространстве существующего потока. Иногда возникает иерархия потоков с от¬ 
ношениями типа «родительский—дочерний поток», но чаще всего иерархия от¬ 
сутствует и все потоки считаются равнозначными. Независимо от иерархических 
отношений, создающему потоку чаще всего возвращается идентификатор потока, 
который дает имя новому потоку. 

Выполнив задачу, поток может прекратить работу, вызвав библиотечную про¬ 
цедуру. скажем, ікгеа<і_ехіІ. После этого поток исчезает и уже не рассматривается 
планировщиком. В некоторых потоковых системах один поток может ждать пре¬ 
кращения работы другого (определенного) потока. Для этого вызывается проце¬ 
дура, например 1кгеас1_шаИ. Процедура блокирует вызывающий процедуру поток, 
пока другой поток (определенный) не прекратит работу. В этом отношении созда¬ 
ние и завершение потоков очень похожи на создание и завершение процессов с 
практически такими же параметрами. 

Еще одно распространенное обращение потока — ікгеасІ_уіеІсІ — позволяет по¬ 
току добровольно «уступать свою очередь» другому потоку. Это важный момент, 
поскольку в случае потоков не существует прерывания по таймеру, позволяюще¬ 
го установить режим разделения времени, как это было в случае процессов. Пото¬ 
кам необходимо быть вежливыми и время от времени самим уступать процессор 
другим потокам. Существуют и процедуры, позволяющие одному потоку подож¬ 
дать, пока другой завершит какое-либо действие, оповестить о том, что он закон¬ 
чил какое-либо действие и т. п. 

Несмотря на то что потоки часто бывают полезными, они существенно услож¬ 
няют программную модель. Представьте себе системный вызов Гогк в ІЖІХ. Если 
у родительского процесса было много потоков, должно ли это свойство распрост¬ 
раняться на дочерний процесс? Если нет, то процесс может неправильно функцио¬ 
нировать, поскольку все потоки могут оказаться необходимы. 

Но что произойдет, если поток родительского процесса будет блокирован вы¬ 
зовом геасі с клавиатуры, а у дочернего процесса столько же потоков, сколько у ро¬ 
дительского? Будут ли теперь блокированы два потока — один из родительского 
процесса, другой из дочернего? И если с клавиатуры поступит строка, получат ли 
оба потока ее копию? Или только один — тогда какой? Эта же проблема возника¬ 
ет при работе с открытыми сетевыми соединениями. 

Другой класс проблем связан с тем, что потоки совместно используют большое 
количество структур данных. Что произойдет, если один поток закроет файл в то 
время, когда другой считывает из него данные? Представьте себе, что одному по¬ 
току стало недостаточно памяти и он просит выделить дополнительную память. 
На полпути происходит переключение потоков, и теперь новый поток также заме¬ 
чает, что ему не хватает памяти, и просит выделить дополнительную память. В этой 
ситуации память может быть выделена дважды. Все эти проблемы можно решить, 
но для создания корректно работающих многопоточных программ необходима 
тщательная и всесторонне обдуманная разработка. 
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Использование потоков 

Настало время объяснить, почему же, собственно, потоки так необходимы. Основ¬ 
ной причиной является выполнение большинством приложений существенного 
числа действий, некоторые из них могут время от времени блокироваться. Схему 
программы можно существенно упростить, если разбить приложение на несколь¬ 
ко последовательных потоков, запущенных в квазипараллельном режиме. 

С этим рассуждением мы уже сталкивались — оно являлось аргументом в пользу 
существования процессов, не так ли? Мы можем рассуждать на языке параллель¬ 
ных процессов вместо прерываний, таймеров и переключателей контекста. В случае 
потоков придется добавить еще один элемент: возможность совместного исполь¬ 
зования параллельными объектами адресного пространства и всех содержащихся 
в нем данных. Для определенных приложений эта возможность является суще¬ 
ственной, и в таких случаях схема параллельных процессов (с разными адресны¬ 
ми пространствами) не подходит. 

Еще одним аргументом в пользу потоков является легкость их создания и унич¬ 
тожения (поскольку с потоком не связаны никакие ресурсы). В большинстве сис¬ 
тем на создание потока уходит примерно в 100 раз меньше времени, чем на созда¬ 
ние процесса. Это свойство особенно полезно, если необходимо динамическое и 
быстрое изменение числа потоков. 

Третьим аргументом является производительность. Концепция потоков не дает 
увеличения производительности, если все они ограничены возможностями про¬ 
цессора. Но когда имеется одновременная потребность в выполнении большого 
объема вычислений и операций ввода-вывода, наличие потоков позволяет совме¬ 
щать эти виды деятельности во времени, тем самым увеличивая общую скорость 
работы приложения. 

И наконец, концепция потоков полезна в системах с несколькими процессора¬ 
ми, где возможен настоящий параллелизм. Мы еще вернемся к этой теме в главе 8. 

Необходимость потоков проще продемонстрировать на конкретных примерах. 
Возьмем в качестве первого примера текстовый редактор. Большинство текстовых 
редакторов выводят текст на экран монитора в том виде, в котором он будет напе¬ 
чатан. В частности, разрывы строк и страниц находятся на своих местах, и пользо¬ 
ватель может при необходимости их откорректировать (например, удалить непол¬ 
ные строки вверху и внизу страницы, неприемлемые с эстетической точки зрения). 

Представьте себе, что пользователь пишет книгу. С точки зрения автора проще 
всего хранить книгу в одном файле, чтобы легче было искать отдельные разделы, 
выполнять глобальную замену и т. п. С другой стороны, можно хранить каждую 
главу в отдельном файле. Но было бы крайне неудобно хранить каждый раздел и 
параграф в своем файле — в случае глобальных изменений пришлось бы редакти¬ 
ровать сотни файлов. Например, если предполагаемый стандарт ххх был утверж¬ 
ден только перед отправкой книги в печать, придется заменять «Черновой стан¬ 
дарт ххх» на «Стандарт ххх» в последнюю минуту. Эта операция делается одной 
командой в случае одного файла и, напротив, займет очень много времени, если 
придется редактировать каждый из 300 файлов, на которые разбита книга. 

Теперь представьте себе, что произойдет, если пользователь удалит одно пред¬ 
ложение на первой странице документа, в котором 800 страниц. Пользователь 
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перечитал эту страницу и решил исправить предложение на 600-й странице. Он дает 
команду текстовому редактору перейти на страницу с номером 600 (например, за¬ 
дав поиск фразы, встречающейся только на этой странице). Текстовому редактору 
придется переформатировать весь документ вплоть до 600 страницы, поскольку 
до форматирования он не будет знать, где начинается эта страница. Это может за¬ 
нять довольно много времени и вряд ли обрадует пользователя. 

В этом случае помогут потоки. Пусть текстовый редактор написан в виде двух¬ 
поточной программы. Один поток взаимодействует с пользователем, а второй пе¬ 
реформатирует документ в фоновом режиме. Как только предложение на первой 
странице было удалено, интерактивный поток дает команду фоновому потоку пе¬ 
реформатировать весь документ. В то время как первый поток продолжает отсле¬ 
живать и выполнять команды с клавиатуры или мыши — предположим, прокру¬ 
чивает первую страницу, — второй поток быстро переформатирует книгу. Немного 
везения — и форматирование будет закончено раньше, чем пользователь захочет 
перейти к 600 странице, и тогда команда будет выполнена мгновенно. 

Раз уж мы об этом задумались, почему бы не добавить третий поток? Большин¬ 
ство текстовых редакторов автоматически сохраняет редактируемый текст раз в 
несколько минут, чтобы пользователь не лишился плодов работы целого дня в слу¬ 
чае аварийного завершения программы, отказа системы или перебоев с питанием. 
Этим может заниматься третий поток, не отвлекая два оставшихся (рис. 2.6). 




Клавиатура 


Диск 


Рис. 2.6. Текстовый редактор стремя потоками 


Если бы программа была однопоточной, тогда при каждой операции сохра¬ 
нения файла все команды с клавиатуры и мыши игнорировались до окончания 
дисковой операции. У пользователя это создало бы впечатление низкой произ¬ 
водительности. В качестве альтернативы команды с клавиатуры и мыши могут 
прерывать сохранение файла, обеспечивая высокую производительность, но при¬ 
водя к сложной программной модели, управляемой прерываниями. Программная 
модель с тремя потоками существенно проще. Первый поток взаимодействует 
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с пользователем, второй при необходимости переформатирует документ, а третий 
периодически сохраняет на диске содержимое оперативной памяти. 

Очевидно, что в этом случае модель с тремя процессами не подойдет, посколь¬ 
ку всем трем необходимо работать с одним и тем же документом. Три же потока 
совместно используют общую память, и все три имеют доступ к документу. 

Ситуация выглядит точно так же в случае многих других интерактивных про¬ 
грамм. Динамическая электронная таблица — программа, позволяющая пользова¬ 
телю работать с матрицей, некоторые элементы которой заданы пользователем. 
Остальные элементы вычисляются на основе заданных элементов с использо¬ 
ванием достаточно сложных формул. Если пользователь изменяет один элемент 
матрицы, это приводит к пересчету многих других элементов. Пока один поток 
занят пересчетом элементов в фоновом режиме, другой может позволить пользо¬ 
вателю в это время вносить дальнейшие изменения. А третий поток может перио¬ 
дически сохранять резервную копию файла на диске. 

Теперь давайте рассмотрим еще одну ситуацию, в которой необходимы пото¬ 
ки: сервер \ѵеЬ-сайта. На сервер приходят запросы, и клиенту отсылается содер¬ 
жимое запрашиваемых \ѵеЬ-страниц. У большинства \ѵеЬ-сайтов некоторые стра¬ 
ницы существенно более посещаемы, чем другие. Например, главная страница 
компании $опу посещается гораздо чаще, чем страница с техническими специфи¬ 
кациями конкретных моделей записывающих видеокамер. Для повышения эффек¬ 
тивности работы сервер использует эту особенность, храня содержимое особо по¬ 
пулярных страниц в основной памяти (чтобы не надо было каждый раз обращаться 
за ними на диск). Этот раздел памяти называется кэш, и он используется также во 
многих других ситуациях. 

На рис. 2.7 представлен один из способов организации \ѵеЬ-сервера. Один поток, 
называемый диспетчером, считывает приходящие по сети запросы. После этого 
он находит свободный (то есть блокированный) рабочий поток и передает ему 
запрос, скажем, записывая указатель сообщения в специальное слово, связанное 
с каждым потоком. Затем диспетчер активизирует ждущий поток, переводя его 
из состояния блокировки в состояние готовности. 

Процесс ѵѵеЬ-сервера 


V Пространство 
( пользователя 


Пространство 

ядра 



Рис. 2.7. Многопоточный ѵгеЬ-сервер 
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После активации рабочий поток проверяет возможность удовлетворения за¬ 
проса в кэше \ѵеЬ-страниц, к которому имеют доступ все потоки. В случае отрица¬ 
тельного ответа поток начинает операцию чтения геасі, чтобы считать страницу с 
диска, и блокируется до завершения этой операции. Когда рабочий поток блоки¬ 
руется, для запуска выбирается следующий поток, им может оказаться диспетчер 
или другой готовый рабочий поток. 

Эта модель позволяет создать сервер в виде набора последовательных потоков. 
Программа диспетчера состоит из бесконечного цикла, в который входит получе¬ 
ние запроса и передача его рабочему потоку. Программа каждого рабочего потока 
состоит из бесконечного цикла, включающего получение запроса от диспетчера и 
проверку кэша на наличие запрашиваемой страницы. При наличии страницы в 
кэше она отсылается клиенту, и рабочий процесс блокируется в ожидании нового 
запроса. При отсутствии страницы в кэше она считывается с диска, отсылается 
клиенту, и рабочий процесс блокируется в ожидании нового запроса. 

Приблизительный набросок программы представлен на рис. 2.8. Здесь и в даль¬ 
нейшем ТКІІЕ предполагается константой, равной 1. Переменные Ъи/ и ра§е явля¬ 
ются структурами, подходящими соответственно для хранения запроса и \ѵеЬ- 
страницы. 


иЬіІе(ТРШЕ) { 

де1:_пех1:_гечие5І: (&ЪиТ) ; 
ЬапДоТТ_иогк(4ЬиГ); 

} 


а 


мЬІІе (ТКЦЕ) { 

иаіС_Тог_иог к(&ЪиТ) 

1оок_Гог_раде_іп_сасЬе (&ЪиГ, іраде) ; 
ІГ(раде_пор_іп_сасЬе (&раде)) 

геаД_раде_Тгот_сіі5к (&ЪиГ, іраде) ; 
геСигп_раде(&раде); 

} 


б 


Рис. 2.8. Приблизительный набросок программы для рис. 2.7: поток диспетчера (а); 

рабочий поток (б) 


Теперь рассмотрим, как можно было написать \ѵеЬ-сервер в отсутствие пото¬ 
ков. Одна из возможностей — заставить его работать как один поток. Основной 
цикл получает запрос, проверяет его и удовлетворяет, затем переходит к следующе¬ 
му. Пока \ѵеЬ-страница считывается с диска, сервер простаивает и не обрабатывает 
другие поступающие запросы. Если сервер расположен на выделенном компьюте¬ 
ре — а чаще всего именно так и бывает, — процессор простаивает, пока \ѵеЬ-стра- 
ница считывается с диска. В результате в единицу времени однопоточное прило¬ 
жение может обрабатывать существенно меньшее число запросов. Таким образом, 
использование нескольких потоков дает заметное увеличение производительнос¬ 
ти, хотя каждый поток программируется последовательно, обычным способом. 

Итак, мы рассмотрели два возможных варианта: \ѵеЬ-сервер с одним потоком 
и несколькими потоками. Представьте себе, что многопоточная система невозмож¬ 
на, но хочется увеличить эффективность системы с одним потоком. Возможен тре¬ 
тий вариант \ѵеЬ-сервера в случае существования версии системного запроса геасі 
без блокировки. На сервер приходит запрос, его считывает и проверяет единствен¬ 
ный поток. Если запрашиваемая \ѵеЬ-страница есть в кэше — хорошо, если нет — 
запускается дисковая операция без блокировки. 
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Сервер записывает в таблицу текущее состояние запроса и переходит к следу¬ 
ющему событию. Оно может быть как новым запросом, так и ответом предыдущей 
операции. В случае нового запроса он начинает обрабатываться, в противном слу¬ 
чае соответствующая информация считывается из таблицы и формируется ответ. 
В случае процедуры ввода-вывода с диска без блокировки ответ может иметь фор¬ 
му сигнала или прерывания. 

При такой схеме модель «последовательных процессов», которая была справед¬ 
лива в первых двух ситуациях, не действует. Состояние программы должно явно 
сохраняться и восстанавливаться в таблице каждый раз, когда сервер переключа¬ 
ется между запросами. Фактически мы имитируем потоки и стеки, причем не са¬ 
мым простым способом. Такая модель, в которой каждому расчету соответствует 
сохраненное состояние и есть несколько событий, которые могут изменить это со¬ 
стояние, называется машиной с конечным числом состояний или конечным авто¬ 
матом. Эта модель широко используется в программировании. 

Теперь должно быть ясно, какие преимущества привносят потоки. Они дают 
возможность сохранить модель последовательных процессов, выполняющих бло¬ 
кирующие системные запросы (например, для ввода-вывода с диска), и тем не 
менее добиться параллелизма. Системные запросы с блокировкой упрощают про¬ 
граммирование, а параллелизм увеличивает производительность. Однопоточиый 
сервер сохраняет простоту программирования, связанную с наличием блокирую¬ 
щих системных запросов, но уступает в производительности. Модель конечного 
автомата существенно повышает производительность при помощи параллелизма, 
но использует системные запросы без блокировки, что усложняет программиро¬ 
вание. Эти модели представлены в табл. 2.4. 


Таблица 2.4. Три способа конструирования сервера 


Модель 

Характеристики 

Потоки 

Процесс с одним потоком 

Конечный автомат 

Параллелизм, системные запросы с блокировкой 

Нет параллелизма, системные запросы с блокировкой 
Параллелизм, системные запросы без блокировки, прерывания 


Третий пример необходимости потоков — приложения, оперирующие большим 
количеством данных. Обычно считывается блок данных, обрабатывается и снова 
записывается. Проблема состоит в том, что при наличии только системных за¬ 
просов с блокировкой процесс будет блокироваться при чтении и записи данных. 
Необходимо избегать простоя процессора, особенно при таком большом объеме 
вычислений. 

Решение проблемы — в потоках. Процесс можно разбить на входной поток, об¬ 
рабатывающий поток и выходной поток. Входной поток считывает данные и по¬ 
мещает их во входной буфер. Обрабатывающий поток считывает данные из вход¬ 
ного буфера, обрабатывает их и помещает в выходной буфер, а выходной поток 
считывает их оттуда и записывает обратно на диск. В такой модели считывание 
данных, обработка и запись происходят одновременно. Разумеется, это возможно 
лишь в том случае, когда системные вызовы блокируют только вызывающий по¬ 
ток, а не весь процесс. 
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Реализация потоков в пространстве 
пользователя 

Есть два основных способа реализации пакета потоков: в пространстве пользовате¬ 
ля и ядре. Выбор между ними остается спорным вопросом, и возможна смешанная 
реализация. Мы рассмотрим оба способа, а также их преимущества и недостатки. 

Первый метод состоит в размещении пакета потоков целиком в пространстве 
пользователя. При этом ядро о потоках ничего не знает и управляет обычными, 
однопоточными процессами. Наиболее очевидное преимущество этой модели со¬ 
стоит в том, что пакет потоков на уровне пользователя можно реализовать даже в 
операционной системе, не поддерживающей потоки. Все операционные системы 
когда-то относились к этой категории, а некоторые относятся до сих пор. 

Подобные реализации имеют в своей основе одинаковую общую схему, пред¬ 
ставленную на рис. 2.9, а. Потоки работают поверх системы поддержки испол¬ 
нения программ, которая является набором процедур, управляющих потоками. 
С четырьмя из них мы уже знакомы: (кгеасІ_сгеа(е, ікгеасІ_ехіІ, Скгеае1_іеаіС и 
(к?еасі_уіеІ(і, но обычно их больше. 

Процесс Поток Процесс Поток 




исполнения программ 

а б 

Рис. 2.9. Пакет потоков в пространстве пользователя (а); 
пакет потоков, управляемый ядром (б) 

Если управление потоками происходит в пространстве пользователя, каждому 
процессу необходима собственная таблица потоков для отслеживания потоков 
в процессе. Эта таблица аналогична таблице процессов, с той лишь разницей, что 
она отслеживает лишь характеристики потоков, такие как счетчик команд, указа¬ 
тель вершины стека, регистры, состояние и т. п. Когда поток переходит в состоя¬ 
ние готовности или блокировки, вся информация, необходимая для повторного 
запуска, хранится в таблице потоков подобному тому, как в ядре хранится инфор¬ 
мация о процессах в таблице процессов. 
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Когда поток, ожидая окончания действия другого потока в том же процессе, 
делает нечто, что может привести к локальной блокировке, он вызывает процеду¬ 
ру системы поддержки исполнения программ. Процедура проверяет необходи¬ 
мость блокирования потока. В этом случае процедура сохраняет регистры потока 
в таблице потоков, ищет в таблице поток, готовый к запуску, и загружает его со¬ 
храненные значения в регистры машины. Как только указатель стека и счетчик 
команд переключены, работа нового потока возобновляется автоматически. Если 
у процессора есть команда, позволяющая за одну инструкцию сохранить все реги¬ 
стры, и еще одна, чтобы загрузить их все заново, переключение потоков может быть 
выполнено с помощью очень небольшого количества инструкций. Такое переклю¬ 
чение потоков по крайней мере на порядок быстрее, чем переключения в режим 
ядра, и является серьезным аргументом в пользу управления потоками в простран¬ 
стве пользователя. 

Но существует одно серьезное отличие потоков от процессов. В тот момент, 
когда поток завершает на время свою работу, например, когда он вызывает про¬ 
цедуру ікгеа(1_уіеЫ, программа ікгеа(1_уіеЫ может сама сохранить информацию 
о потоке в таблице потоков. Более того, она может после этого вызвать плани¬ 
ровщик потоков для выбора следующего потока. Процедура, сохраняющая инфор¬ 
мацию о потоке, и планировщик являются локальными процедурами, и их вызов 
существенно более эффективен, чем вызов ядра. Не требуются прерывание, пере¬ 
ключение контекста, сохранение кэша и т. п., что существенно ускоряет переклю¬ 
чение потоков. 

Потоки, реализованные на уровне пользователя, имеют и другие преимущества. 
Они позволяют каждому процессу иметь собственный алгоритм планирования. 
Для некоторых приложений, например приложений с потоком «сборки мусора», 
оказывается удобным не задумываться о том, что поток может остановиться в не¬ 
подходящий момент. Эти приложения также лучше масштабируются, поскольку 
потоки ядра неизменно занимают некоторое пространство в таблице и стековое 
пространство в ядре, что может стать проблемой в случае большого числа потоков. 

Несмотря на более высокую производительность, с реализацией потоков на 
уровне пользователя связаны и некоторые серьезные проблемы. Первой из них 
является проблема реализации блокирующих системных запросов. Представьте, 
что поток начинает считывание с клавиатуры до того, как была нажата хотя бы 
одна клавиша. Было бы неприемлемо позволить потоку выполнить системный за¬ 
прос, поскольку это остановило бы все потоки. Одной из основных целей исполь¬ 
зования потоков было предоставление возможности каждому потоку использовать 
блокирующие запросы, но так, чтобы один блокированный поток не мешал осталь¬ 
ным. Не очень понятно, как достичь этой цели, если использовать блокирующие 
системные запросы. 

Можно сделать все системные запросы не блокирующими (как, например, за¬ 
прос на чтение с клавиатуры геасі, который возвращал бы 0 байт в случае отсутствия 
данных), но это потребует неприемлемых изменений операционной системы. 
Вспомните, ведь одним из основных аргументов в пользу потоков на уровне 
пользователя была возможность работы в существующих операционных системах. 
К тому же изменение семантики запроса геасі повлекло бы за собой изменения во 
многих пользовательских программах. 
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Оказалось, что существует альтернатива, если имеется возможность узнавать 
заранее, последует ли за запросом блокировка. В некоторых версиях ІЖІХ есть 
системный запрос зеіесі;, позволяющий узнать о наличии или отсутствии блоки¬ 
ровки у последующего запроса геасі. При наличии такого системного запроса биб¬ 
лиотечную процедуру геасі можно заменить новой, сначала выполняющей запрос 
зеіесі;, а потом запрос геасі, если за ним не последует блокировки. Если блокировка 
должна произойти, то запрос не выполняется и запускается другой поток. В следу¬ 
ющий момент, когда система поддержки исполнения программ получит управление, 
она может проверить еще раз, последует ли за запросом геасі блокировка. Такой под¬ 
ход требует перезаписи части библиотеки системных запросов, неэффективен и 
не отличается изяществом, но выбор не так уж велик. Код, который помещается 
вокруг системного запроса для проверки на блокировку, называется чехлом (даскеС) 
или упаковкой (\ѵгаррег). 

Схожей проблемой является ошибка из-за отсутствия страницы. Мы рассмот¬ 
рим ее подробнее в главе 4. На данный момент нам важно, что компьютер можно 
настроить так, чтобы не вся программа находилась в основной памяти. Если про¬ 
грамма производит вызов или переход к той инструкции, которой нет в памяти, 
возникает ошибка из-за отсутствия страницы, и операционная система берет не¬ 
достающую часть программы с диска. Именно эта ситуация называется ошибкой 
из-за отсутствия страницы. Процесс блокируется, пока необходимая инструкция 
не будет найдена и считана. Если поток приводит к ошибке из-за отсутствия стра¬ 
ницы, ядро, не знающее о существовании потоков, блокирует весь процесс цели¬ 
ком, до завершения операции чтения с диска, несмотря на наличие остальных нор¬ 
мально функционирующих потоков. 

Еще одной проблемой потоков на уровне пользователя является тот факт, что 
при запуске одного потока ни один другой поток не будет запущен, пока первый 
поток добровольно не отдаст процессор. Внутри одного процесса нет прерываний 
по таймеру, в результате чего невозможно создать планировщик для поочередно¬ 
го выполнения потоков. Планировщик ничего не сможет сделать, пока поток не 
окажется в системе поддержки исполнения программ по собственному желанию. 

Одним из решений этой проблемы может стать ежесекундное прерывание, пе¬ 
редающее управление системе поддержки исполнения программ, но этот способ 
достаточно груб и неудобен. Периодические прерывания по таймеру с более высо¬ 
кой частотой не всегда возможны, а если и возможны, то издержки все равно будут 
существенными. Более того, возможно, что потоку необходимы свои прерывания 
по таймеру, которые будут конфликтовать с прерываниями системы поддержки 
исполнения программ. 

Еще один, и, возможно, наиболее серьезный аргумент против использования 
потоков на уровне пользователя состоит в том, что программисты хотят использо¬ 
вать потоки именно в тех приложениях, в которых потоки часто блокируются, 
например в многопоточном \ѵеЬ-сервере. Эти потоки все время посылают систем¬ 
ные запросы. И ядру, перехватившему управление, чтобы выполнить системный 
запрос, не составит труда заодно переключить потоки, если один из них блокиро¬ 
ван. При этом исключается необходимость постоянных обращений к системе с за¬ 
просом зеіесі; для проверки наличия или отсутствия блокировки у последующего 
запроса геасі. А для приложений, которые полностью ограничены возможностями 
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процессора и редко блокируются, потоки вообще не нужны. Вряд ли кто-либо ста¬ 
нет всерьез применять потоки для вычисления первых п простых чисел или игры 
в шахматы. 

Реализация потоков в ядре 

Теперь рассмотрим ситуацию, в которой ядро знает о существовании потоков 
и управляет ими. В этом случае система поддержки исполнения программ не 
нужна, как показано на рис. 2.9, б. Нет необходимости и в наличии таблицы по¬ 
токов в каждом процессе, вместо этого есть единая таблица потоков, отслежива¬ 
ющая все потоки системы. Если потоку необходимо создать новый поток или за¬ 
вершить имеющийся, он выполняет запрос ядра, который создает или завершает 
поток, внося изменения в таблицу потоков. 

Таблица потоков, находящаяся в ядре, содержит регистры, состояние и другую 
информацию о каждом потоке. Информация та же, что и в случае управления 
потоками на уровне пользователя, только теперь она располагается не в простран¬ 
стве пользователя (внутри системы поддержки исполнения программ), а в ядре. 
Эта информация является подмножеством информации, которую традиционное 
ядро хранит о каждом из своих одноиоточных процессов (то есть подмножеством 
состояния процесса). Дополнительно ядро содержит обычную таблицу процессов, 
отслеживающую все процессы системы. 

Все запросы, которые могут блокировать поток, реализуются как системные 
запросы, что требует значительно больших временных затрат, чем вызов процеду¬ 
ры системы поддержки исполнения программ. Когда поток блокируется, ядро по 
желанию запускает другой поток из этого же процесса (если есть поток в состоя¬ 
нии готовности) либо поток из другого процесса. При управлении потоками на 
уровне пользователя система поддержки исполнения программ запускает потоки 
из одного процесса, пока ядро не передает процессор другому процессу (или пока 
не кончаются потоки, находящиеся в состоянии готовности). 

Поскольку создание и завершение потоков в ядре требует относительно боль¬ 
ших расходов, некоторые системы используют повторное использование потоков. 
После завершения поток помечается как нефункционирующий, но в остальном его 
структура данных, хранящаяся в ядре, не затрагивается. Позже, когда нужно со¬ 
здать новый поток, реактивируется отключенный поток, что позволяет сэкономить 
на некоторых накладных расходах. При управлении потоками на уровне пользо¬ 
вателя повторное использование потоков тоже возможно, но поскольку наклад¬ 
ных расходов, связанных с управлением потоками, в этом случае существенно 
меньше, то и смысла в этом меньше. 

Управление потоками в ядре не требует новых не блокирующих системных за¬ 
просов. Более того, если один поток вызвал ошибку из-за отсутствия страницы, ядро 
легко может проверить, есть ли в этом процессе потоки в состоянии готовности, 
и запустить один из них, пока требуемая страница считывается с диска. Основным 
недостатком управления потоками в ядре является существенная цена системных 
запросов, поэтому постоянные операции с потоками (создание, завершение и т. п.) 
приведут к увеличению накладных расходов. 
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Смешанная реализация 

С целью совмещения преимуществ реализации потоков на уровне ядра и на уров¬ 
не пользователя были опробованы многие способы смешанной реализации. Один 
из методов заключается в использовании управления ядром и последующем муль¬ 
типлексировании потоков на уровне пользователя, как показано на рис. 2.10. 


Мультиплексирование потоков 
пользователя из потока ядра 



В такой модели ядро знает только о потоках своего уровня и управляет ими. 
Некоторые из этих потоков могут содержать по нескольку потоков пользова¬ 
тельского уровня, мультиплексированных поверх них. Потоки пользовательского 
уровня создаются, завершаются и управляются так же, как потоки уровня пользо¬ 
вателя в процессе, запущенном в не поддерживающей многопоточность системе. 
Предполагается, что у каждого потока ядра есть набор потоков на уровне пользо¬ 
вателя, которые используют его по очереди. 

Активация планировщика 

Многие исследователи старались совместить преимущества реализации потоков 
на уровне ядра (простота реализации) и реализации потоков на уровне пользова¬ 
теля (высокая производительность). Ниже мы рассмотрим один из таких подхо¬ 
дов, разработанный Андерсоном [12], который называется активацией планиров¬ 
щика. Соответствующие разработки описаны в [104, 296]. 

Целью активации планировщика является имитация функциональности пото¬ 
ков ядра, но с большей производительностью и гибкостью, свойственной потокам 
уровня пользователя. В частности, пользовательские потоки не должны выполнять 
специальные системные запросы без блокировки или заранее должны проверять, 
не вызовет ли запрос блокировку. Тем не менее, когда поток блокируется систем¬ 
ным запросом или ошибкой из-за отсутствия страницы, должна оставаться воз¬ 
можность запустить другой поток этого же процесса (если такой есть и находится 
в состоянии готовности). 
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Увеличение эффективности достигается за счет уменьшения количества не¬ 
нужных переходов между пространством пользователя и ядром. Например, если 
поток блокирован в ожидании действий другого потока, совершенно не обязатель¬ 
но обращаться к ядру, что позволяет избежать накладных расходов по переходу 
«пользователь—ядро». Система поддержки исполнения программ, работающая 
в пространстве пользователя, может блокировать синхронизирующий поток и са¬ 
мостоятельно выбрать другой. 

При использовании активации планировщика ядро назначает каждому процес¬ 
су некоторое количество виртуальных процессоров и позволяет системе поддерж¬ 
ки исполнения программ (в пространстве пользователя) распределять потоки по 
процессорам. Этот метод можно использовать и в мультипроцессорной системе, 
заменяя виртуальные процессоры реальными. Исходное число виртуальных про¬ 
цессоров, соответствующих одному процессу, равно единице, но процесс может 
запросить больше процессоров и позже вернуть их. Ядро также может забрать 
виртуальный процессор у одного процесса и отдать другому, более нуждающему¬ 
ся в нем в данный момент. 

В основе механизма работы этой схемы лежит следующее утверждение. Если 
ядро знает, что поток блокирован (например, если он выполнил блокирующий 
системный запрос или вызвал ошибку из-за отсутствия страницы), ядро оповеща¬ 
ет об этом систему поддержки исполнения программ процесса, пересылая через 
стек в качестве параметров номер потока в запросе и описание случившегося. Опо¬ 
вещение происходит при помощи активации ядром в определенном начальном 
адресе системы поддержки исполнения программ, что приблизительно аналогич¬ 
но сигналу в ІЛѴІХ. Этот метод называется ирсаіі («вызов вверх», также иногда 
именуемый обратным вызовом — саІІЬаск — в противоположность обычным вы¬ 
зовам, производящимся из верхних уровней в нижние). 

Активизированная таким образом система поддержки исполнения программ 
перепланирует свои потоки, обычно помечая текущий поток как блокированный, 
выбирая следующий поток из списка, устанавливая значения его регистров и за¬ 
пуская его. Позже, когда ядро получает информацию о том, что поток снова готов 
к работе (например, канал, из которого он пытался считывать данные, теперь их 
содержит, или недостающая страница считана с диска), оно выполняет еще один 
обратный вызов, информируя об этом систему поддержки исполнения программ. 
Система поддержки исполнения программ по своему усмотрению запускает бло¬ 
кированный поток тут же или помещает его в список готовых процессов, чтобы 
запустить позже. 

При возникновении аппаратного прерывания во время работы потока пользо¬ 
вателя процессор переключается в режим ядра. Если прерывание вызвано собы¬ 
тием, не имеющим отношения к прерванному процессу, например завершением 
операции ввода-вывода другого процесса, по завершении работы обработчика пре¬ 
рываний прерванный поток возвращается в состояние, в котором он находился до 
прерывания. Если же процесс заинтересован в прерывании (например, вызванном 
поступлением страницы, которую ждал один из потоков процесса), прерванный 
поток не запускается вновь. Вместо этого прерванный поток приостанавливается, 
и на этом виртуальном процессоре запускается система поддержки исполнения про¬ 
грамм с состоянием прерванного потока на стеке. Дальнейшее зависит от системы 
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поддержки исполнения программ, решающей, запустить ли на этом процессоре 
прерванный поток, другой, находящийся в состоянии готовности, или какой-либо 
третий. 

Недостатком метода активации планировщика является существенная зависи¬ 
мость от обратных вызовов, концепция, нарушающая свойственную любой мно¬ 
гоуровневой системе структуру. Обычно уровень п + 1 может вызывать процедуры 
уровня п, но не наоборот. Обратные вызовы противоречат этому фундаменталь¬ 
ному принципу. 


Всплывающие потоки 

Потоки часто используются в распределенных системах. Важным примером мо¬ 
жет служить обработка входящих сообщений, например запросов на обслужива¬ 
ние. Традиционный подход заключается в наличии процесса или потока, который 
блокируется по системному запросу гесіеѵе, ожидая входящего сообщения. Когда 
сообщение прибывает, оно принимается и обрабатывается. 

Возможен и принципиально другой подход, при котором по прибытии сооб¬ 
щения система создает новый поток для его обработки. Такой поток называется 
всплывающим, его схема проиллюстрирована на рис. 2.11. Основным преиму¬ 
ществом всплывающих потоков является их «свежесть» — у такого потока нет ис¬ 
тории: регистров, стека и прочей информации, которую нужно восстанавливать. 
Всплывающие потоки абсолютно «стерильны» и идентичны, что позволяет созда¬ 
вать их быстро. Новый поток обрабатывает входящее сообщение. Использова¬ 
ние всплывающих потоков позволяет значительно сократить промежуток време¬ 
ни между прибытием сообщения и началом его обработки. 



Сеть 


а б 

Рис. 2.11. Создание нового потока по прибытии сообщения: до прибытия сообщения (а); 

после прибытия сообщения (б) 
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При использовании всплывающих потоков необходимо предварительное пла¬ 
нирование. Например, в каком процессе возникнет новый поток? Если система 
поддерживает потоки, работающие в контексте ядра, новый поток может возникнуть 
там (именно поэтому мы не показали ядро на рис. 2.11). Создание всплывающих 
потоков в пространстве ядра всегда быстрее и проще, чем в пространстве пользо¬ 
вателя. К тому же всплывающему потоку в пространстве ядра проще получить 
доступ ко всем таблицам ядра и устройств ввода-вывода, что может оказаться по¬ 
лезным при обработке прерываний. С другой стороны, наличие ошибок в потоке, 
расположенном в пространстве ядра, может нанести существенно больший ущерб. 
Например, если поток работает слишком долго и невозможно воспользоваться 
приоритетным прерыванием, это может привести к потере входных данных. 

Как сделать однопоточную программу 
многопоточной 

Многие из существующих программ были написаны для однопоточных процес¬ 
сов. Сделать их многопоточными гораздо сложнее, чем это может показаться на 
первый взгляд. Ниже мы рассмотрим некоторые из возможных трудностей. 

Прежде всего, программа потока обычно состоит из нескольких процедур, так 
же как и процесс. У этих процедур могут быть локальные переменные, глобаль¬ 
ные переменные и параметры. Проблем с локальными переменными и параметра¬ 
ми не будет, зато проблемы будут с переменными, которые являются глобальны¬ 
ми для потока, но не глобальными для всей программы. Эти переменные являются 
глобальными с точки зрения процедур одного потока (которые ими пользуются, 
как пользовались бы любыми другими глобальными переменными), но не имеют 
никакого отношения к другим потокам. 

В качестве примера рассмотрим переменную егто в ІЖІХ. Если процесс (или 
поток) выполняет неудачный системный запрос, код ошибки записывается в егто. 
На рис. 2.12 поток 1 выполняет системный запрос ассе$$, чтобы узнать, имеет ли 
он разрешение на доступ к конкретному файлу. Операционная система возвра¬ 
щает ответ в глобальной переменной егто. После этого управление возвращается 
к потоку 1. Однако прежде, чем у него появляется возможность считать значение 
егто, планировщик решает, что поток 1 уже достаточно попользовался процессо¬ 
ром и пора переключиться на поток 2. Поток 2 выполняет запрос ореп, завершаю¬ 
щийся неудачей, в результате чего значение егто изменяется и предыдущее зна¬ 
чение теряется. После того как поток 1 вновь получит управление, он прочитает 
неверное значение егто, и дальнейшие его действия будут неправильными. 

Существует несколько различных решений проблемы. Одно из решений — зап¬ 
ретить глобальные переменные вообще. Какой бы заманчивой ни была эта идея, 
она вступит в противоречие с большей частью существующего программного обес¬ 
печения. Другое решение — предоставить каждому потоку собственные глобаль¬ 
ные переменные, как показано на рис. 2.13. В этом случае конфликт исключается, 
поскольку у каждого потока будет своя копия егто и остальных глобальных пере¬ 
менных. Это решение фактически приводит к появлению новых уровней видимо¬ 
сти переменных: переменные, доступные всем процедурам потока (в дополнение 
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к уже имеющимся уровням видимости переменных, доступных только одной про¬ 
цедуре), и переменные, доступные всей программе. 

Поток 1 Поток 2 


і г 

5 Запрос ассезз 

(§- (установлено значение еггпо) 


Запрос ореп 

(установлено новое значение еггпо) 


Значение еггпо считывается 

Рис. 2.12. Конфликт между потоками при использовании глобальной переменной 



Рис. 2.13. У потоков могут быть собственные глобальные переменные 


Обеспечить доступ к собственным глобальным переменным не очень просто, 
поскольку в большинстве языков программирования есть способы описания локаль¬ 
ных и глобальных переменных, но не промежуточных разновидностей. Можно от¬ 
вести под глобальные переменные отдельный участок памяти и рассматривать их 
как дополнительные параметры процедур. Несмотря на некоторую неуклюжесть, 
этот метод работает. 

В качестве альтернативы можно написать новые библиотечные процедуры, ко¬ 
торые будут создавать, записывать и считывать переменные, глобальные для по¬ 
тока. Первый запрос будет выглядеть примерно так: 

сгеаГе_д1оЬаК"ЬиГр1:г"); 
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Этот запрос отводит участок памяти под указатель, называющийся Ъи/ріг, в ди¬ 
намической памяти или в отдельном участке памяти, зарезервированном для вызы¬ 
вающего потока. Не имеет значения, где именно расположен этот участок памяти, 
важно, что лишь вызывающий поток имеет к нему доступ. Если другой поток со¬ 
здаст глобальную переменную с таким же именем, она будет размещаться в другом 
участке памяти и конфликта потоков не будет. 

Для доступа к глобальной переменной нужно два запроса: один, чтобы запи¬ 
сать ее значение, и другой — чтобы его считать. Для записи будет использоваться 
что-то вроде 

зеЕдП оЬаП С "Ьи^рЕг" ,&ЬиТ); 

Этот запрос сохраняет значение указателя в участке памяти, созданном запро¬ 
сом сгеаіе фіЪаІ. Запрос на чтение может выглядеть как 

Ьи1 : ріг=геас1_д1 оЬаІ ( "Ьиі'рѣг" ): 

Запрос возвращает адрес Для доступа к данным, хранящийся в глобальной 
переменной. 

Другим препятствием может стать тот факт, что большинство библиотечных 
процедур не являются реентерабельными. Это означает, что при их написании 
не предполагалась ситуация, при которой процедуре будет необходимо ответить 
на второй запрос, не закончив ответа на первый. Например, пересылку сообщения 
по сети можно организовать следующим образом: сообщение помещается в буфер, 
затем эмулируется прерывание в ядро для его отсылки. Что произойдет, если 
один поток поместит сообщение в буфер, а затем прерывание по таймеру приве¬ 
дет к передаче управления второму потоку, который тут же поместит в этот буфер 
свое сообщение? 

Подобная же проблема возникает с процедурами распределения памяти ( таііос 
в ІЖІХ), управляющими таблицами использования памяти (в виде связного спис¬ 
ка доступных участков памяти). Пока процедура таііос занята переписыванием 
таблиц, таблицы могут временно находиться в несовместимом состоянии, с указа¬ 
телями, никуда не указывающими. Если в этот момент произойдет переключение 
потоков и от нового потока придет запрос, может быть использован неправильный 
указатель, что приведет к нарушению работы программы. Решение всех подобных 
проблем равнозначно полному переписыванию библиотеки. 

Другим решением может быть снабжение каждой процедуры чехлом ()аске(;), 
устанавливающим бит, означающий, что эта процедура используется. Любая по¬ 
пытка использования процедуры другим потоком до окончания выполнения пре¬ 
дыдущего запроса блокируется. Этот метод можно использовать, но он практичес¬ 
ки исключает параллелизм. 

Теперь рассмотрим сигналы. Одни из них связаны с потоками, тогда как другие — 
нет. Например, если поток выполняет запрос аіагш, результирующий сигнал по 
логике должен вернуться к этому потоку. Однако если потоки реализованы в про¬ 
странстве пользователя, ядро ничего не знает об их существовании и вряд ли на¬ 
правит сигнал к правильному потоку. Ситуация еще больше усложняется, если 
одновременно у процесса может быть только один необработанный аварийный 
сигнал, а несколько потоков выполняют запрос аіагш независимо друг от друга. 
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Другие сигналы, такие как прерывание с клавиатуры, не связаны с потоками. 
Кто должен их перехватывать? Один назначенный поток? Все потоки? Специаль¬ 
но созданный всплывающий поток? Что случится, если один поток изменит обра¬ 
ботчик сигнала, не сообщив об этом остальным потокам? А что если один поток 
хочет перехватить определенный сигнал (например, СТРІ.+С с клавиатуры), а друго¬ 
му потоку этот сигнал нужен, чтобы прервать процесс? Подобная ситуация может 
возникнуть, если один или более потоков пользуются стандартными библиотечны¬ 
ми процедурами, а остальные — процедурами, написанными пользователем. Эти 
потоки абсолютно несовместимы. Вообще говоря, управлять сигналами даже в од¬ 
нопоточной среде достаточно сложно. При переходе к многопоточному окружению 
обработка сигналов проще не становится. 

Последняя проблема, связанная с потоками, — управление стеками. Во многих 
системах при переполнении стека процесса ядро автоматически увеличивает его. 
Если у процесса несколько потоков, стеков тоже должно быть несколько. Если 
ядро не знает о существовании этих стеков, оно не может их автоматически увели¬ 
чивать при переполнении. Ядро может даже не связать ошибки памяти с перепол¬ 
нением стеков. 

Разумеется, эти проблемы не являются непреодолимыми, но на их примере 
хорошо видно, что введение потоков в существующую систему невозможно без 
тщательной и продуманной реконструкции всей системы. По крайней мере, при¬ 
дется изменить семантику системных запросов и переписать библиотеки. И ре¬ 
зультат ваших трудов должен быть совместим с существующими программами для 
процессов с одним потоком. Дополнительную информацию о потоках можно 
найти в [149, 225]. 


Межпроцессное взаимодействие 

Процессам часто бывает необходимо взаимодействовать между собой. Например, 
в конвейере ядра выходные данные первого процесса должны передаваться второ¬ 
му и т. д. по цепочке. Поэтому необходимо правильно организованное взаимодей¬ 
ствие между процессами, по возможности не использующее прерываний. В этом 
разделе мы рассмотрим некоторые аспекты межпроцессного взаимодействия 
(ІРС, іпіегргосезз соттипісаііоп). 

Проблема разбивается на три пункта. Первый мы уже упомянули: передача 
информации от одного процесса другому. Второй связан с контролем над дея¬ 
тельностью процессов: как гарантировать, что два процесса не пересекутся в кри¬ 
тических ситуациях (представьте себе два процесса, каждый из которых пытается 
завладеть последним мегабайтом памяти). Третий касается согласования действий 
процессов: если процесс А должен поставлять данные, а процесс В выводить их на 
печать, то процесс В должен подождать и не начинать печатать, пока не поступят 
данные от процесса А. Мы рассмотрим все три случая в следующем подразделе. 

Важно понимать, что два из трех описанных пунктов в равной мере относятся 
и к потокам. Первый — передача информации — в случае потоков проблемой не 
является, поскольку у потоков общее адресное пространство (передача информа¬ 
ции между потоками с разным адресным пространством уже является проблемой 
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передачи информации между процессами). Остальные два с тем же успехом каса¬ 
ются потоков: те же проблемы, и те же решения. Мы будем рассматривать эти си¬ 
туации в контексте процессов, но имейте в виду, что эти же рассуждения приме¬ 
нимы и для потоков. 


Состояние состязания 

В некоторых операционных системах процессы, работающие совместно, могут со¬ 
обща использовать некое общее хранилище данных. Каждый из процессов может 
считывать из общего хранилища данных и записывать туда информацию. Это хра¬ 
нилище представляет собой участок в основной памяти (возможно, в структуре 
данных ядра) или файл общего доступа. Местоположение совместно используемой 
памяти не влияет на суть взаимодействия и возникающие проблемы. Рассмотрим 
межпроцессное взаимодействие на простом, но очень распространенном примере: 
спулер печати. Если процессу требуется вывести на печать файл, он помещает имя 
файла в специальный каталог спулера. Другой процесс, демон печати, периоди¬ 
чески проверяет наличие файлов, которые нужно печатать, печатает файл и уда¬ 
ляет его имя из каталога. 

Представьте, что каталог спулера состоит из большого числа сегментов, прону¬ 
мерованных 0, 1, 2, ..., в каждом их которых может храниться имя файла. Также 
есть две совместно используемые переменные: оиі , указывающая на следующий 
файл для печати, и ш, указывающая на следующий свободный сегмент. Эти две 
переменные можно хранить в одном файле (состоящем из двух слов), доступном 
всем процессам. Пусть в данный момент сегменты с 0 по 3 пусты (эти файлы уже 
напечатаны), а сегменты с 4 по 6 заняты (эти файлы ждут своей очереди на печать). 
Более или менее одновременно процессы АиВ решают поставить файл в очередь 
на печать. Описанная ситуация схематически изображена на рис. 2.14. 


Директория 

спулера 


4 

5 

6 
7 



Рис. 2.14. Два процесса хотят одновременно получить доступ 
к совместно используемой памяти 

В соответствии с законом Мерфи (он звучит примерно так: «Если что-то пло¬ 
хое может случиться, оно непременно случится») возможна следующая ситуация. 



аЬс 


ргод.с 


ргод.п 


оиІ=4 


іп=7 
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Процесс А считывает значение (7) переменной от и сохраняет его в локальной пере¬ 
менной пехі_/гее__5ІоІ. После этого происходит прерывание по таймеру, и процессор 
переключается на процесс В. Процесс В, в свою очередь, считывает значение пере¬ 
менной іп и сохраняет его (опять 7) в своей локальной переменной пехІ_/гее_8ІоІ. 
В данный момент оба процесса считают, что следующий свободный сегмент — 
седьмой. 

Процесс В сохраняет в каталоге спулера имя файла и заменяет значение іп на 8, 
затем продолжает заниматься своими задачами, не связанными с печатью. 

Наконец управление переходит к процессу А, и он продолжает с того места, 
на котором остановился. Он обращается к переменной пехі_/гее_5ІоІ , считыва¬ 
ет ее значение и записывает в седьмой сегмент имя файла (разумеется, удаляя 
при этом имя файла, записанное туда процессом В). Затем он заменяет значение 
іп на 8 ( пехі_[гее_йоІ +1=8). Структура каталога спулера не нарушена, так что 
демон печати не заподозрит ничего плохого, но файл процесса В не будет напе¬ 
чатан. Пользователь, связанный с процессом В, может в этой ситуации полдня 
описывать круги вокруг принтера, ожидая требуемой распечатки. Ситуации, в ко¬ 
торых два (и более) процесса считывают или записывают данные одновременно 
и конечный результат зависит от того, какой из них был первым, называются 
состояниями состязания. Отладка программы, в которой возможно состояние 
состязания, вряд ли может доставить удовольствие. Результаты большинства 
тестовых прогонов будут хорошими, но изредка будет происходить нечто стран¬ 
ное и необъяснимое. 

Критические области 

Как избежать состязания? Основным способом предотвращения проблем в этой и 
любой другой ситуации, связанной с совместным использованием памяти, файлов 
и чего-либо еще, является запрет одновременной записи и чтения разделенных 
данных более чем одним процессом. Говоря иными словами, необходимо взаим¬ 
ное исключение. Это означает, что в тот момент, когда один процесс использует 
разделенные данные, другому процессу это делать будет запрещено. Проблема, 
описанная в предыдущем параграфе, возникла из-за того, что процесс В начал 
работу с одной из совместно используемых переменных до того, как процесс А ее 
закончил. Выбор подходящей примитивной операции, реализующей взаимное 
исключение, является серьезным моментом разработки операционной системы, 
и мы рассмотрим его подробно в дальнейшем. 

Проблему исключения состояний состязания можно сформулировать на абст¬ 
рактном уровне. Некоторый промежуток времени процесс занят внутренними рас¬ 
четами и другими задачами, не приводящими к состояниям состязания. В другие 
моменты времени процесс обращается к совместно используемым данным или 
выполняет какое-то другое действие, которое может привести к состязанию. Часть 
программы, в которой есть обращение к совместно используемым данным, назы¬ 
вается критической областью или критической секцией. Если нам удастся избе¬ 
жать одновременного нахождения двух процессов в критических областях, мы 
сможем избежать состязаний. 
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Несмотря на то что это требование исключает состязание, его недостаточно для 
правильной совместной работы параллельных процессов и эффективного исполь¬ 
зования общих данных. Для этого необходимо выполнение четырех условий: 

1. Два процесса не должны одновременно находиться в критических обла¬ 
стях. 

2. В программе не должно быть предположений о скорости или количестве 
процессоров. 

3. Процесс, находящийся вне критической области, не может блокировать дру¬ 
гие процессы. 

4. Невозможна ситуация, в которой процесс вечно ждет попадания в крити¬ 
ческую область. 

В абстрактном виде требуемое поведение процессов представлено на рис. 2.15. 
Процесс А попадает в критическую область в момент времени Г,. Чуть позже, в мо¬ 
мент времени Т 2 , процесс В пытается попасть в критическую область, но ему это 
не удается, поскольку в критической области уже находится процесс Л, а два 
процесса не должны одновременно находиться в критических областях. Поэто¬ 
му процесс В временно приостанавливается, до наступления момента времени Т 3 , 
когда процесс А выходит из критической области. В момент времени Г 4 процесс В 
также покидает критическую область, и мы возвращаемся в исходное состояние, 
когда ни одного процесса в критической области не было. 


Процесс А попадает 


Процесс А покидаат 



Т 2 блокирован т 3 


Время -► 

Рис. 2.15. Взаимное исключение с использованием критических областей 


Взаимное исключение с активным ожиданием 

В этом разделе мы рассмотрим различные способы реализации взаимного исклю¬ 
чения с целью избежать вмешательства в критическую область одного процесса 
при нахождении там другого и связанных с этим проблем. 
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Запрещение прерываний 

Самое простое решение состоит в запрещении всех прерываний при входе процес¬ 
са в критическую область и разрешение прерываний по выходе из области. Если 
прерывания запрещены, невозможно прерывание по таймеру. Поскольку процессор 
переключается с одного процесса на другой только по прерыванию, отключение пре¬ 
рываний исключает передачу процессора другому процессу. Таким образом, за¬ 
претив прерывания, процесс может спокойно считывать и сохранять совместно ис¬ 
пользуемые данные, не опасаясь вмешательства другого процесса. 

И все же было бы неразумно давать пользовательскому процессу возможность 
запрета прерываний. Представьте себе, что процесс отключил все прерывания и в 
результате какого-либо сбоя не включил их обратно. Операционная система на 
этом может закончить свое существование. К тому же в многопроцессорной сис¬ 
теме запрещение прерываний повлияет только на тот процессор, который выпол¬ 
нит инструкцию сіізаЫе. Остальные процессоры продолжат работу и сохранят до¬ 
ступ к разделенным данным. 

С другой стороны, для ядра характерно запрещение прерываний для некоторых 
команд при работе с переменными или списками. Возникновение прерывания в мо¬ 
мент, когда, например, список готовых процессов находится в неопределенном со¬ 
стоянии, могло бы привести к состоянию состязания. Итак, запрет прерываний 
бывает полезным в самой операционной системе, но это решение неприемлемо 
в качестве механизма взаимного исключения для пользовательских процессов. 

Переменные блокировки 

Теперь попробуем найти программное решение. Рассмотрим одну совместно ис¬ 
пользуемую переменную блокировки, изначально равную 0. Если процесс хочет 
попасть в критическую область, он предварительно считывает значение переменной 
блокировки. Если переменная равна 0, процесс изменяет ее на 1 и входит в крити¬ 
ческую область. Если же переменная равна 1, то процесс ждет, пока ее значение 
сменится на 0. Таким образом, 0 означает, что ни одного процесса в критической 
области нет, а 1 означает, что какой-либо процесс находится в критической области. 

К сожалению, у этого метода те же проблемы, что и в примере с каталогом спу¬ 
лера. Представьте, что один процесс считывает переменную блокировки, обнару¬ 
живает, что она равна 0, но прежде, чем он успевает изменить ее на 1, управление 
получает другой процесс, успешно изменяющий ее на 1. Когда первый процесс 
снова получит управление, он тоже заменит переменную блокировки на 1 и два 
процесса одновременно окажутся в критических областях. 

Можно подумать, что проблема решается повторной проверкой значения пе¬ 
ременной, прежде чем заменить ее, но это не так. Второй процесс может получить 
управление как раз после того, как первый процесс закончил вторую проверку, но 
еще не заменил значение переменной блокировки. 

Строгое чередование 

Третий метод реализации взаимного исключения иллюстрирован на рис. 2.16. Этот 
фрагмент программного кода, как и многие другие в этой книге, написан на С. 
Язык С был выбран, поскольку практически все существующие операционные 
системы написаны на С (или С++), а не на ^ѵа, МосІиІаЗ, Разсаі ит. п. Язык С 
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обладает всеми необходимыми свойствами для написания операционных систем: 
это мощный, эффективный и предсказуемый язык программирования. Язык ^ѵа, 
например, не является предсказуемым, поскольку у программы, написанной на 
нем, может в критический момент закончиться свободная память и она вызовет 
«сборщика мусора» в исключительно неподходящее время. В случае С это невоз¬ 
можно, поскольку в С процедура «сбора мусора» в принципе отсутствует. Срав¬ 
нительный анализ С, С++, ^ѵа и еще четырех языков представлен в [268]. 


иЪіІе (ТКЧЕ) { 

ѵЬіІе(Сигп!=0) /*1оор*/; 

сгіСіса1_гедіоп (); 

еигп-1; 

полсгіСіса1_гедіоп () ; 

) 


иЬіІе (ТКІІЕ) { 

ѵЬіІе(Сигп!=0) /*1оор*/; 

сгіСіса1_гедіоп () ; 

Тигп=0 ; 

попсгіСіса1_гедіоп(); 

) 


а б 

Рис. 2.16. Предлагаемое решение проблемы критической области: процесс 0 (а); 
процесс 1 (б). В обоих случаях необходимо удостовериться в наличии точки 
с запятой, ограничивающей цикл мИіІе 

На рис. 2.16 целая переменная іит, изначально равная 0, отслеживает, чья 
очередь входить в критическую область. Вначале процесс 0 проверяет значение 
іит, считывает 0 и входит в критическую область. Процесс 1 также проверяет зна¬ 
чение іит, считывает 0 и после этого входит в цикл, непрерывно проверяя, когда 
же значение іит будет равно 1. Постоянная проверка значения переменной в ожи¬ 
дании некоторого значения называется активным ожиданием. Подобного спосо¬ 
ба следует избегать, поскольку он является бесцельной тратой времени процес¬ 
сора. Активное ожидание используется только в случае, когда есть уверенность 
в небольшом времени ожидания. Блокировка, использующая активное ожидание, 
называется спин-блокировкой. 

Когда процесс 0 покидает критическую область, он изменяет значение іит на 1, 
позволяя процессу 1 попасть в критическую область. Предположим, что процесс 1 
быстро покидает свою критическую область, так что оба процесса теперь находят¬ 
ся вне критической области, и значение іит равно 0. Теперь процесс 0 выполняет 
весь цикл быстро, выходит из критической области и устанавливает значение іит 
равным 1. В этот момент значение іит равно 1, и оба процесса находятся вне кри¬ 
тической области. 

Неожиданно процесс 0 завершает работу вне критической области и возвраща¬ 
ется к началу цикла. Но войти в критическую область он не может, поскольку зна¬ 
чение іит равно 1 и процесс 1 находится вне критической области. Процесс 0 за¬ 
виснет в своем цикле иІтЛе, ожидая, пока процесс 1 изменит значение Шгп наО. 
Получается, что метод поочередного доступа к критической области не слишком 
удачен, если один процесс существенно медленнее другого. 

Эта ситуация нарушает третье из сформулированных нами условий: один про¬ 
цесс блокирован другим, не находящимся в критической области. Возвратимся к 
примеру с каталогом спулера: если заменить критическую область процедурой счи¬ 
тывания и записи в каталог спулера, процесс 0 не сможет послать файл на печать, 
поскольку процесс 1 занят чем-то другим. 
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Фактически этот метод требует, чтобы два процесса попадали в критичес¬ 
кие области строго по очереди. Ни один из них не сможет попасть в критическую 
область (например, послать файл на печать) два раза подряд. Хотя этот алгоритм 
и исключает состояния состязания, его нельзя рассматривать всерьез, поскольку 
он нарушает третье условие успешной работы двух параллельных процессов с со¬ 
вместно используемыми данными. 


Алгоритм Петерсона 

Датский математик Деккер (Т. Беккег) был первым, кто разработал программное 
решение проблемы взаимного исключения, не требующее строгого чередования. 
Подробное изложение алгоритма можно найти в [46]. 

В 1981 году Петерсон (С. Ь. РеГегзоп) разработал существенно более простой 
алгоритм взаимного исключения. С этого момента алгоритм Деккера стал считать¬ 
ся устаревшим. Алгоритм Петерсона, представленный в листинге 2.1, состоит из 
двух процедур, написанных на АИ5І С, что предполагает необходимость прототи¬ 
пов для всех определяемых и используемых функций. В целях экономии места мы 
не будем приводить прототипы для этого и последующих примеров. 


Листинг 2.1. Решение Петерсона для взаимного исключения 


#<1еГіпе РАІ.5Е О 
ІбеГіпе ™е 1 
#беРі пе N 2 
іпѣ ѣигп : 

іпі: ШегезІесЮТ; 
ѵоіВ еп1;ег_геді оп(т ргосезз); 
{ 


/* Количество процессов */ 

/* Чья сейчас очередь? */ 

/* Все переменные изначально равны 0 (РА15Е) */ 
/* Процесс 0 или 1 */ 


Ш оТПег: /* Номер второго процесса */ 

оІНег - 1 - ргосезз; /* Противоположный процесс */ 

іпРегезІесІЕргосезз] = ШЕ; /* Индикатор интереса*/ 

Ригп - ргосезз; /* Установка флага*/ 

міп'іе (Ригп — ргосевз && і ггЬегезТеВСоТМег] — ТКУЕ) /* Пустой оператор */; 


ѵоій 1 еаѵе_гед1оп(ігѵь ргосезз) /* ргосезз: процесс, покидающий критическую область */ 

{ 

іпРегезРесІЕргосезз] - РА1.5Е; /* Индикатор выхода из критической области */ 

} 


Прежде чем обратиться к совместно используемым переменным (то есть перед 
тем, как войти в критическую область), процесс вызывает процедуру етег_гефт со 
своим номером (0 или 1) в качестве параметра. Поэтому процессу при необходимо¬ 
сти придется подождать, прежде чем входить в критическую область. После выхода 
из критической области процесс вызывает процедуру Іеаѵе_ге@іоп, чтобы обозначить 
свой выход и тем самым разрешить другому процессу вход в критическую область. 

Рассмотрим работу алгоритма более подробно. Исходно оба процесса находят¬ 
ся вне критических областей. Процесс 0 вызывает епІег_ге§іоп, задает элементы 
массива и устанавливает переменную Шт равной 0. Поскольку процесс 1 не заин¬ 
тересован в попадании в критическую область, процедура возвращается. Теперь, 
если процесс 1 вызовет еп{ег_ге§іоп, ему придется подождать, пока іпіегезіесі [0] 
примет значение РАЬЗЕ, а это произойдет только в тот момент, когда процесс 0 
вызовет процедуру Іеаѵе_ге§іоп, чтобы покинуть критическую область. 
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Представьте, что оба процесса вызвали епіег_ге§іоп практически одновремен¬ 
но. Оба сохранят свои номера в Іит. Сохранится номер того процесса, который 
был вторым, а предыдущий номер будет утерян. Предположим, что вторым был 
процесс 1, так что значение Іит равно 1. Когда оба процесса дойдут до опера¬ 
тора ѵѵЬЯе, процесс 0 войдет в критическую область, а процесс 1 останется в цикле 
и будет ждать, пока процесс 0 выйдет из критической области. 

Команда Т5І- 

Рассмотрим решение, требующее участия аппаратного обеспечения. Многие ком¬ 
пьютеры, особенно разработанные с расчетом на несколько процессоров, имеют 
команду 

Т51 КХ.ЮСК 

(Те$Е апсі 5еЬ Ьоск — проверить и заблокировать), которая действует следующим 
образом. В регистр КХ считывается содержимое слова памяти Іоск, а в ячейке памя¬ 
ти Іоск сохраняется некоторое ненулевое значение. Гарантируется, что операция 
считывания слова и сохранения неделима — другой процесс не может обратиться 
к слову в памяти, пока команда не выполнена. Процессор, выполняющий коман¬ 
ду Т5І-, блокирует шину памяти, чтобы остальные процессоры не могли обратить¬ 
ся к памяти. 

Воспользуемся командой Т$(_. Пусть совместно используемая переменная Іоск 
управляет доступом к разделенной памяти. Если значение переменной Іоск рав¬ 
но 0, любой процесс может изменить его на 1 и обратиться к разделенной памяти, 
и затем изменить его обратно на 0, пользуясь обычной командой шоѵе. 

Как использовать эту команду для взаимного исключения? Решение приведе¬ 
но в листинге 2.2. Здесь представлена подпрограмма из четырех команд, написан¬ 
ная на фиктивном (но типичном) ассемблере. Первая команда копирует старое 
значение Іоск в регистр и затем устанавливает значение переменной равное 1. По¬ 
том старое значение сравнивается с нулем. Если оно ненулевое, значит, блокиров¬ 
ка уже была установлена и проверка начинается сначала. Рано или поздно значе¬ 
ние окажется нулевым (это означает, что процесс, находившийся в критической 
области, вышел из нее), и подпрограмма возвращается, установив блокировку. 
Программа просто помещает 0 в переменную Іоск. Специальной команды процес¬ 
сора не требуется. 

Листинг 2.2. Вход и выход из критической области с помощью команды Т5І. 

епіег_гедіоп; 


Т51 КЕЕІЕТЕКЛОСК 

1 значение Іоск копируется в регистр, значение переменной 
устанавливается равным 1 

СМР КЕСІ$ТЕК,#0 

1 Старое значение Іоск сравнивается с нулем 

Ж епіег_гедіоп 

1 Если оно ненулевое, значит, блокировка уже была установлена, 
поэтому цикл завершается 

КЕТ 

I Возврат к вызывающей программе, процесс вошел в критическую 
область 

гедіоп; 

МОѴЕ 10СК.#0 

КЕТ 

1 Сохранение 0 в переменной Іоск 
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Одно решение проблемы критических областей теперь очевидно. Прежде чем 
попасть в критическую область, процесс вызывает процедуру еп1ег_ге$оп, кото¬ 
рая выполняет активное ожидание вплоть до снятия блокировки, затем она уста¬ 
навливает блокировку и возвращается. По выходе из критической области процесс 
вызывает процедуру Іеаѵе_ге§іоп, помещающую 0 в переменную Іоск. Как и во всех 
остальных решениях проблемы критической области, для корректной работы 
процесс должен вызывать эти процедуры своевременно, в противном случае взаим¬ 
ное исключение не удастся. 

Примитивы межпроцессного взаимодействия 

Оба решения — Петерсона и с использованием команды Т5І- — корректны, но они 
обладают одним и тем же недостатком: использованием активного ожидания. В сущ¬ 
ности, оба они реализуют следующий алгоритм: перед входом в критическую область 
процесс проверяет, можно ли это сделать. Если нельзя, процесс входит в тугой 
цикл, ожидая возможности войти в критическую область. 

Этот алгоритм не только бесцельно расходует время процессора, но, кроме это¬ 
го, он может иметь некоторые неожиданные последствия. Рассмотрим два процес¬ 
са: Н, с высоким приоритетом, и і, с низким приоритетом. Правила планирования 
в этом случае таковы, что процесс Н запускается немедленно, как только он ока¬ 
зывается в состоянии ожидания. В какой-то момент, когда процесс I находится в 
критической области, процесс Н оказывается в состоянии ожидания (например, 
он закончил операцию ввода-вывода). Процесс Н попадает в состояние активного 
ожидания, но поскольку процессу I во время работающего процесса Н никогда не 
будет предоставлено процессорное время, у процесса Ь не будет возможности вый¬ 
ти иэ критической области, и процесс Н навсегда останется в цикле. Эту ситуацию 
иногда называют проблемой инверсии приоритета. 

Теперь рассмотрим некоторые примитивы межпроцессного взаимодействия, 
применяющиеся вместо циклов ожидания, в которых лишь напрасно расходуется 
процессорное время. Эти примитивы блокируют процессы в случае запрета на вход 
в критическую область. Одной из простейших является пара примитивов зіеер и 
иакеир. Примитив зіеер — системный запрос, в результате которого вызывающий 
процесс блокируется, пока его не запустит другой процесс. У запроса ѵѵакеир есть 
один параметр — процесс, который следует запустить. Также возможно наличие 
одного параметра у обоих запросов — адреса ячейки памяти, используемой для 
согласования запросов ожидания и запуска. 

Проблема производителя и потребителя 

В качестве примера использования этих примитивов рассмотрим проблему про¬ 
изводителя и потребителя, также известную как проблема ограниченного буфе¬ 
ра. Два процесса совместно используют буфер ограниченного размера. Один из 
них, производитель, помещает данные в этот буфер, а другой, потребитель, считы¬ 
вает их оттуда. (Можно обобщить задачу на случай т производителей и п потреби¬ 
телей, но мы рассмотрим случай с одним производителем и одним потребителем, 
поскольку это существенно упрощает решение.) 
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Трудности начинаются в тот момент, когда производитель хочет поместить 
в буфер очередную порцию данных и обнаруживает, что буфер полон. Для произво¬ 
дителя решением является ожидание, пока потребитель полностью или частично 
не очистит буфер. Аналогично, если потребитель хочет забрать данные из буфера, 
а буфер пуст, потребитель уходит в состояние ожидания и выходит из него, как 
только производитель положит что-нибудь в буфер и разбудит его. 

Это решение кажется достаточно простым, но оно приводит к состояниям со¬ 
стязания, как и пример с каталогом спулера. Нам нужна переменная соипі для от¬ 
слеживания количества элементов в буфере. Если максимальное число элементов, 
хранящихся в буфере, равно Ы, программа производителя должна проверить, не 
равно ли N значение соипі прежде, чем поместить в буфер следующую порцию дан¬ 
ных. Если значение соипі равно Ы, то производитель уходит в состояние ожида¬ 
ния; в противном случае производитель помещает данные в буфер и увеличивает 
значение соипі. 

Код программы потребителя прост: сначала проверить, не равно ли значение 
соипі нулю. Если равно, то уйти в состояние ожидания; иначе забрать порцию дан¬ 
ных из буфера и уменьшить значение соипі. Каждый из процессов также должен 
проверять, не следует ли активизировать другой процесс, и в случае необходимос¬ 
ти проделывать это. Программы обоих процессов представлены в листинге 2.3. 

Листинг 2.3. Проблема производителя и потребителя с неустранимым состоянием 
соревнования 

#беПіпе N 100 /* Максимальное количество элементов в буфере */ 

іпі соипі - 0: /* Текущее количество элементов в буфере */ 

ѵоісі ргосіисег(ѵоісі) 

{ 

іпЕ Нет: 

ѵфіііе (ТКІ1Е) { /* Повторять вечно */ 

Пет = ргосІисе_Иет( ): /* Сформировать следующий элемент */ 

И (соипі == Ю 5Іеер(): /* Если буфер полон, уйти в состояние ожидания */ 

іп$еіИ_Иет(Иет) : /* Поместить элемент в буфер */ 

соипі = соипі +1: /* Увеличить количество элементов в буфере */ 

іТ (соипі -= 1) ь/акеир(сопвитег): /* Был ли буфер пуст? */ 

■ } 

} 

ѵоісі сопзитегСѵоісІ) 

{ 

іпі Нет: 

мМІе (ТЕШЕ) { /* Повторять вечно */ 

И (соипі == 0) БІеерО; /* Если буфер пуст, уйти в состояние ожидания */ 

Нет = гетоѵе_Пет( ); /* Забрать элемент из буфера */ 

соипі = соипі - 1: /* Уменьшить счетчик элементов в буфере */ 

И (соипі == N - 1) шкеир(ргосіисег) : /* Был ли буфер полон? */ 
соп5ите_Иет(Иет): /* Отправить элемент на печать */ 



Для описания на языке С системных вызовов зіеер и макеир мы представили их 
в виде вызовов библиотечных процедур. В стандартной библиотеке С их нет, но 
они будут доступны в любой системе, в которой присутствуют такие системные 
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вызовы. Процедуры іпзеті_іІет и гетоѵе_)іет помещают элементы в буфер и из¬ 
влекают их оттуда. 

Теперь давайте вернемся к состоянию состязания. Его возникновение возмож¬ 
но, поскольку доступ к переменной соипі не ограничен. Может возникнуть следу¬ 
ющая ситуация: буфер пуст, и потребитель только что считал значение перемен¬ 
ной соипі, чтобы проверить, не равно ли оно нулю. В этот момент планировщик 
передал управление производителю, производитель поместил элемент в буфер и 
увеличил значение соипі, проверив, что теперь оно стало равно 1. Зная, что перед 
этим оно было равно 0 и потребитель находился в состоянии ожидания, произво¬ 
дитель активизирует его с помощью вызова хюакеир. 

Но потребитель не был в состоянии ожидания, так что сигнал активизации про¬ 
пал впустую. Когда управление перейдет к потребителю, он вернется к считанно¬ 
му когда-то значению соипі, обнаружит, что оно равно 0, и уйдет в состояние ожи¬ 
дания. Рано или поздно производитель наполнит буфер и также уйдет в состояние 
ожидания. Оба процесса так и останутся в этом состоянии. 

Суть проблемы в данном случае состоит в том, что сигнал активизации, при¬ 
шедший к процессу, не находящемуся в состоянии ожидания, пропадает. Если бы 
не это, проблемы бы не было. Быстрым решением может быть добавление бита 
ожидания активизации. Если сигнал активизации послан процессу, не находяще¬ 
муся в состоянии ожидания, этот бит устанавливается. Позже, когда процесс пыта¬ 
ется уйти в состояние ожидания, бит ожидания активизации сбрасывается, но про¬ 
цесс остается активным. Этот бит исполняет роль копилки сигналов активизации. 

Несмотря на то что введение бита ожидания запуска спасло положение в этом 
примере, легко сконструировать ситуацию с несколькими процессами, в которой 
одного бита будет недостаточно. Мы можем добавить еще один бит, или 8, или 32, 
но это не решит проблему. 

Семафоры 

В 1965 году Дейкстра (Е. \Ѵ. Оцкзіга) предложил использовать целую перемен¬ 
ную для подсчета сигналов запуска, сохраненных на будущее [96]. Им был пред¬ 
ложен новый тип переменных, так называемые семафоры, значение которых мо¬ 
жет быть нулем (в случае отсутствия сохраненных сигналов активизации) или 
некоторым положительным числом, соответствующим количеству отложенных 
активизирующих сигналов. 

Дейкстра предложил две операции, сішп и ир (обобщения зіеер и ѵѵакеир). Опе¬ 
рация сішп сравнивает значение семафора с нулем. Если значение семафора боль¬ 
ше нуля, операция сЫп уменьшает его (то есть расходует один из сохраненных сиг¬ 
налов активации) и просто возвращает управление. Если значение семафора равно 
нулю, процедура сішп не возвращает управление процессу, а процесс переводится 
в состояние ожидания. Все операции проверки значения семафора, его изменения 
и перевода процесса в состояние ожидания выполняются как единое и неделимое 
элементарное действие. Тем самым гарантируется, что после начала операции ни 
один процесс не получит доступа к семафору до окончания или блокирования 
операции. Элементарность операции чрезвычайно важна для разрешения пробле¬ 
мы синхронизации и предотвращения состояния состязания. 
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Операция ир увеличивает значение семафора. Если с этим семафором связаны 
один или несколько ожидающих процессов, которые не могут завершить более 
раннюю операцию боип, один из них выбирается системой (например, случайным 
образом) и ему разрешается завершить свою операцию сіомп. Таким образом, после 
операции ир, примененной к семафору, связанному с несколькими ожидающими 
процессами, значение семафора так и останется равным 0, но число ожидающих 
процессов уменьшится на единицу. Операция увеличения значения семафора и 
активизации процесса тоже неделима. Ни один процесс не может быть блокиро¬ 
ван во время выполнения операции ир, как ни один процесс не мог быть блокиро¬ 
ван во время выполнения операции иакеир в предыдущей модели. 

В оригинале Дейкстра использовал вместо сіомп и ир обозначения Р и V соот¬ 
ветственно. Мы не будем в дальнейшем использовать оригинальные обозначе¬ 
ния, поскольку тем, кто не знает датского языка, эти обозначения ничего не гово¬ 
рят (да и тем, кто знает язык, говорят немного). Впервые обозначения сіомп и ир 
появились в языке А1§о1 68. 


Решение проблемы производителя и потребителя 
с помощью семафоров 

Как показано в листинге 2.4, проблему потерянных сигналов запуска можно ре¬ 
шить с помощью семафоров. Очень важно, чтобы они были реализованы неде¬ 
лимым образом. Стандартным способом является реализация операций сіомп и ир 
в виде системных запросов, с запретом операционной системой всех прерываний на 
период проверки семафора, изменения его значения и возможного перевода про¬ 
цесса в состояние ожидания. Поскольку для выполнения всех этих действий тре¬ 
буется всего лишь несколько команд процессора, запрет прерываний не приносит 
никакого вреда. Если используются несколько процессоров, каждый семафор необ¬ 
ходимо защитить переменной блокировки с использованием команды Т51, чтобы 
гарантировать одновременное обращение к семафору только одного процессора. 
Необходимо понимать, что использование команды Т51. принципиально отличает¬ 
ся от активного ожидания, при котором производитель или потребитель ждут на¬ 
полнения или опустошения буфера. Операция с семафором займет несколько мик¬ 
росекунд, тогда как активное ожидание может затянуться на существенно больший 
промежуток времени. 


Листинг 2.4. Проблема производителя и потребителя с семафорами 


#йеНпе N 100 
ГуребеЕ іпГ зетарітоге 
зетарітоге тиГех = 1: 
зетарітоге етрру - N: 
зетарітоге АіП - 0: 


/* количество сегментов в буфере */ 

/* семафоры - особый вид целочисленных переменных */ 
/* контроль доступа в критическую область */ 

/* число пустых сегментов буфера */ 

/* число полных сегментов буфера */ 


ѵоіб ргобисег(ѵоіб) 


іпГ Нет; 


мНЛе (ТКІІЕ) { /* ТКІІЕ - константа, равная 1*/ 

іГеш = ргобисе_іФет(): /* создать данные, помещаемые в буфер */ 

РомгК&етрГу); /* уменьшить счетчик пустых сегментов буфера */ 

продолжение& 
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Листинг 2.4 ( продолжение ) 


боіѵп(&ш1;ех) : 

/* 

і П2ег1:_і Тет( і Тет); 

/* 

ирС&тибех): 

/* 

ир(&Ти11): 

/* 


} 

} 

ѵоісі сопзитег(ѵоісі) 
{ 


іпб ібет: 


иіітііе (ТОЕ) { 

/* 

сіоіѵп (&Ти11); 

/* 

боіѵп(&ти1:ех); 

/* 

ібет = гетоѵе_ібет(): 

/* 

ир(&ти1:ех); 

/* 

ирС&етрбу) ; 

/* 

соп5ите_і 1;ет( Нет) ; 

/* 


вход в критическую область */ 
поместить в буфер новый элемент */ 
выход из критической области */ 
увеличить счетчик полных сегментов буфера */ 


бесконечный цикл */ 

уменьшить числа полных сегментов буфера */ 
вход в критическую область */ 
удалить элемент из буфера */ 
выход из критической области */ 
увеличить счетчик пустых сегментов буфера */ 
обработка элемента */ 


В представленном решении используются три семафора: один для подсчета за¬ 
полненных сегментов буфера (/ иіі ), другой для подсчета пустых сегментов ( етріу ), 
а третий предназначен для исключения одновременного доступа к буферу произ¬ 
водителя и потребителя ( тиіех ). Значение счетчика /иіі исходно равно нулю, счет¬ 
чик етріу равен числу сегментов в буфере, а тиіех равен 1. Семафоры, исходное 
значение которых равно 1, используемые для исключения одновременного нахож¬ 
дения в критической области двух процессов, называются двоичными семафора¬ 
ми. Взаимное исключение обеспечивается, если каждый процесс выполняет опе¬ 
рацию сіоип перед входом в критическую область и ир после выхода из нее. 

Теперь, когда у нас есть примитивы межпроцессного взаимодействия, вернем¬ 
ся к последовательности прерываний, показанной в табл. 2.2. В системах, исполь¬ 
зующих семафоры, естественным способом скрыть прерывание будет связать с 
каждым устройством ввода-вывода семафор, исходно равный нулю. Сразу после 
запуска устройства ввода-вывода управляющий процесс выполняет операцию сіомп 
на соответствующем семафоре, тем самым входя в состояние блокировки. В случае 
прерывания обработчик прерывания выполняет ир на соответствующем семафоре, 
переводя процесс в состояние готовности. В такой модели пятый шаг в табл. 2.2 
заключается в выполнении ир на семафоре устройства, чтобы следующим шагом 
планировщик смог запустить программу, управляющую устройством. Разумеет¬ 
ся, если в этот момент несколько процессов находятся в состоянии готовности, 
планировщик может выбрать другой, более значимый процесс. Мы рассмотрим 
некоторые алгоритмы планирования позже в этой главе. 

В примере, представленном в листинге 2.4, семафоры использовались двумя 
различными способами. Это различие достаточно значимо, чтобы сказать о нем 
особо. Семафор тиіех используется для реализации взаимного исключения, то есть 
для исключения одновременного обращения к буферу и связанным переменным 
двух процессов. Мы рассмотрим взаимное исключения и методы его реализации 
в следующем разделе. 
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Остальные семафоры использовались для синхронизации. Семафоры /иіі и етріу 
необходимы, чтобы гарантировать, что определенные последовательности собы¬ 
тий происходят или не происходят. В нашем случае они гарантируют, что произ¬ 
водитель прекращает работу, когда буфер полон, а потребитель прекращает рабо¬ 
ту, когда буфер пуст. 


Мьютексы 


Иногда используется упрощенная версия семафора, называемая мьютексом (пшіех, 
сокращение от тиСиаІ ехсіизіоп — взаимное исключение). Мьютекс не способен 
считать, он может лишь управлять взаимным исключением доступа к совместно 
используемым ресурсам или кодам. Реализация мьютекса проста и эффективна, 
что делает использование мьютексов особенно полезным в случае потоков, дей¬ 
ствующих только в пространстве пользователя. 

Мьютекс — переменная, которая может находиться в одном из двух состояний: 
блокированном или неблокированном. Поэтому для описания мьютекса требует¬ 
ся всего один бит, хотя чаще используется целая переменная, у которой 0 означает 
неблокированное состояние, а все остальные значения соответствуют блокирован¬ 
ному состоянию. Значение мьютекса устанавливается двумя процедурами. Если 
поток (или процесс) собирается войти в критическую область, он вызывает проце¬ 
дуру ти1ех_1оск. Если мьютекс не заблокирован (то есть вход в критическую область 
разрешен), запрос выполняется и вызывающий поток может попасть в критическую 
область. 

Напротив, если мьютекс заблокирован, вызывающий поток блокируется до тех 
пор, пока другой поток, находящийся к критической области, не выйдет из нее, 
вызвав процедуру тиІех_ипІоск. Если мьютекс блокирует несколько потоков, то 
из них случайным образом выбирается один. 

Мьютексы легко реализовать в пользовательском пространстве, если доступна 
команда ТЗЕ Код программы для процедур тиіех_Іоск и тиІех_ипІоск в случае по¬ 
токов на уровне пользователя представлен в листинге 2.5. 


Листинг 2.5. Реализация ти1ех_1оск и тиІех_ипІоск 


пнЛех_І оск: 

Т5І_ КЕЕІ5ТЕК.МІІТЕХ 

СМР КЕСІ5ТЕК,#0 
ЛЕ ок 

САІ_1_ РНгеафуіеІсІ 
6МР пнЛех_1оск 

ок: КЕТ 


I Старое значение мьютекса копируется в регистр; 
устанавливается новое значение 1 
Сравнение старого значения с нулем 
Если старое значение было нулем, мьютекс не был 
блокирован. Возврат 

Мьютекс занят, управление передается другому потоку 

Повторить попытку позже 

Возврат, вход в критическую область 


тіЛех_ип! оск: 

МОѴЕ М1)ТЕХ,#0 I Устанавливается значение мьютекса О 

КЕТ I Возврат 

Процедура ти1ех_1оск похожа на процедуру еп(ег_ге^юп в листинге 2.2, но с одним 
существенным отличием. Если процедуре епІег_ге%іоп не удается войти в критичес- 
кукТобласть, она продолжает в цикле проверять наличие блокировки (активное 
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ожидание). В конце концов время, отведенное этому процессу, кончается и пла¬ 
нировщик передает управление другому процессу. Раньше или позже процесс, за¬ 
блокировавший вход в критическую область, освобождает его. 

В случае потоков ситуация кардинально меняется, поскольку нет прерываний 
по таймеру, останавливающих слишком долго работающие потоки. Поток, пыта¬ 
ющийся получить доступ к семафору и находящийся в состоянии активного ожи¬ 
дания, зациклится навсегда, поскольку он не позволит предоставить процессор 
другому потоку, желающему снять блокировку. 

В этой ситуации ти(ех_1оск ведет себя по-другому. Если войти в критическую 
область невозможно, ти(ех_1оск вызовет 1кгеас1_уе1с1, чтобы предоставить процес¬ 
сор другому потоку. Активного ожидания здесь нет. При следующем запуске по¬ 
ток снова проверит блокировку. 

Поскольку вызов ікгесиі _уеЫ является всего лишь обращением к планировщику 
потоков в пространстве пользователя, он выполняется очень быстро. Следователь¬ 
но, ни тиіех_Іоск, ни тиіех_ипІоск не требуют обращений к ядру. Синхронизация 
потоков на уровне пользователя происходит полностью в пространстве пользовате¬ 
ля, с применением процедур, состоящих всего из нескольких команд процессора. 

Система мьютексов, которую мы только что рассмотрели, является только 
скелетом набора запросов. Программное обеспечение часто требует реализации 
разнообразных возможностей, и примитивы синхронизации не являются исклю¬ 
чением. Например, в некоторых реализациях пакета потоков поставляется вызов 
тиіех_ІгуІоск, который либо предоставляет доступ к критической области, либо 
возвращает код ошибки, но в любом случае мгновенно возвращает управление, то 
есть не заставляет поток ждать. Этот запрос дает потоку возможность выбора в слу¬ 
чае наличия альтернативы простому ожиданию. 

Одну тему мы до сих пор обходили стороной, хотя стоило бы по крайней мере 
прояснить ее. В случае потоков в пользовательском пространстве нет проблемы 
доступа потоков к мьютексу, поскольку у всех потоков общее адресное простран¬ 
ство. Тем не менее в большинстве предыдущих моделей, в частности в алгоритме 
Петерсона и семафорах, молчаливо предполагалось, что несколько процессов име¬ 
ют доступ к совместно используемому участку памяти, пусть содержащему одно 
слово. Если адресные пространства процессов несовместны, как мы постоянно ут¬ 
верждали, как они могут совместно использовать переменную іит в алгоритме 
Петерсона, или семафоры, или общий буфер? 

На этот вопрос существует два ответа. Во-первых, некоторые из совместно ис¬ 
пользуемых структур данных, скажем, семафоры, могут храниться в ядре с досту¬ 
пом только через системные запросы. Этот подход решает проблему. Во-вторых, 
большинство современных операционных систем (включая ІЖІХ и \Ѵіп<іо\ѵ5) 
предоставляют возможность совместного использования процессами некоторой 
части адресного пространства. В этом случае возможно разделение буфера и дру¬ 
гих структур данных. В крайнем случае, можно совместно использовать файл. 

Если два или больше процессов разделяют частично или полностью адресные 
пространства, различие между процессами и потоками частично размывается, но 
тем не менее все равно остается. Два процесса с общим адресным пространством 
все равно обладают разными открытыми файлами, аварийными таймерами и про¬ 
чими характеристиками, присущими процессам, в то время как два потока, разде- 




Межпроцессное взаимодействие 


141 


ляющие адресное пространство, разделяют и все остальное. И в любом случае не¬ 
сколько процессов, совместно использующих адресное пространство, никогда не 
будут столь же эффективны, как потоки на уровне пользователя, поскольку уп¬ 
равление потоками всегда происходит через ядро. 

Мониторы 

Межпроцессное взаимодействие с применением семафоров выглядит довольно 
просто, не правда ли? Эта простота кажущаяся. Взгляните внимательнее на поря¬ 
док выполнения процедур сіомп перед помещением или удалением элементов из 
буфера в листинге 2.4. Представьте себе, что две процедуры бсш в программе про¬ 
изводителя поменялись местами, так что значение тиіех было уменьшено раньше, 
чем етріу. Если буфер был заполнен, производитель блокируется, установив тиіех 
на 0. Соответственно, в следующий раз, когда потребитель обратится к буферу, он 
выполнит сіоип с переменной тиіех, равной 0, и тоже заблокируется. Оба процесса 
заблокированы навсегда. Эта неприятная ситуация называется взаимоблокиров¬ 
кой, и мы вернемся к ней в главе 3. 

Вышеизложенная ситуация показывает, с какой аккуратностью нужно обра¬ 
щаться с семафорами. Одна маленькая ошибка, и все останавливается. Это напо¬ 
минает программирование на ассемблере, но на самом деле еще сложнее, посколь¬ 
ку такие ошибки приводят к абсолютно невоспроизводимым и непредсказуемым 
состояниям состязания, взаимоблокировкам и т. п. 

Чтобы упростить написание программ, в 1974 году Хоар (Ноаге) [155] и Бринч 
Хансен (ВгіпсЬ Нашей) [43] предложили примитив синхронизации более высо¬ 
кого уровня, называемый монитором. Их предложения несколько отличались друг 
от друга, как мы увидим дальше. Монитор — набор процедур, переменных и дру¬ 
гих структур данных, объединенных в особый модуль или пакет. Процессы могут 
вызывать процедуры монитора, но у процедур, объявленных вне монитора, нет 
прямого доступа к внутренним структурам данных монитора. В листинге 2.6 пред¬ 
ставлен монитор, написанный на воображаемом языке Рісі§іп Разсаі. 

Листинг 2.6. Монитор 

шотЧог ехатріе 

іпГедег і: 

сопсіігіоп с: 

ргосесіиге ргосІисегО; 


епсі: 

ргосесіиге сопзишегО; 
епсі; 

епсі топіГог; 

Реализации взаимных исключений способствует важное свойство монитора: 
при обращении к монитору в любой момент времени активным может быть только 
один процесс. Мониторы являются структурным компонентом языка программи- 
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рования, поэтому компилятор знает, что обрабатывать вызовы процедур монито¬ 
ра следует иначе, чем вызовы остальных процедур. Обычно при вызове процеду¬ 
ры монитора первые несколько команд процедуры проверяют, нет ли в мониторе 
активного процесса. Если активный процесс есть, вызывающему процессу придет¬ 
ся подождать, в противном случае запрос удовлетворяется. 

Реализация взаимного исключения зависит от компилятора, но обычно ис¬ 
пользуется мьютекс или бинарный семафор. Поскольку взаимное исключение 
обеспечивает компилятор, а не программист, вероятность ошибки гораздо мень¬ 
ше. В любом случае программист, пишущий код монитора, не должен задумывать¬ 
ся о том, как компилятор организует взаимное исключение. Достаточно знать, что, 
обеспечив попадание в критические области через процедуры монитора, можно не 
бояться попадания в критическую область двух процессов одновременно. 

Хотя мониторы предоставляют простой способ реализации взаимного исклю¬ 
чения, этого недостаточно. Необходим также способ блокировки процессов, кото¬ 
рые не могут продолжать свою деятельность. В случае проблемы производителя и 
потребителя достаточно просто поместить все проверки буфера на заполненность 
и пустоту в процедуры монитора, но как процесс заблокируется, обнаружив пол¬ 
ный буфер? 

Решение заключается во введении переменных состояния и двух операций, 
маИ и зідпаі. Когда процедура монитора обнаруживает, что она не в состоянии 
продолжать работу (например, производитель выясняет, что буфер заполнен), она 
выполняет операцию маіГ на какой-либо переменной состояния, скажем, /ц//. Это 
приводит к блокировке вызывающего процесса и позволяет другому процессу 
войти в монитор. 

Другой процесс, в нашем примере потребитель может активизировать ожи¬ 
дающего напарника, например, выполнив операцию зідпаі на той переменной со¬ 
стояния, на которой он был заблокирован. Чтобы в мониторе не оказалось двух 
активных процессов одновременно, нам необходимо правило, определяющее по¬ 
следствия операции зідпаі. Хоар предложил запуск «разбуженного» процесса и 
остановку второго. Бринч Хансен предложил другое решение: процесс, выполнив¬ 
ший зідпаі, должен немедленно покинуть монитор. Иными словами, операция зідпаі 
выполняется только в самом конце процедуры монитора. Мы будем использовать 
это решение, поскольку оно в принципе проще и к тому же легче в реализации. 
Если операция зідпаі выполнена на переменной, с которой связаны несколько за¬ 
блокированных процессов, планировщик выбирает и «оживляет» только один из них. 

Кроме этого, существует третье решение, не основывающееся на предположе¬ 
ниях Хоара и Бринча Хансена: позволить процессу, выполнившему зідпаі, про¬ 
должать работу и запустить ждущий процесс только после того, как первый про¬ 
цесс покинет монитор. 

Переменные состояния не являются счетчиками. В отличие от семафоров они 
не аккумулируют сигналы, чтобы впоследствии воспользоваться ими. Это означа¬ 
ет, что в случае выполнения операции зідпаі на переменной состояния, с которой 
не связано ни одного блокированного процесса, сигнал будет утерян. Проще гово¬ 
ря, операция маіТ должна выполняться прежде, чем зідпаі . Это правило существен¬ 
но упрощает реализацию. На практике это правило не создает проблем, поскольку 
отслеживать состояния процессов при необходимости не очень трудно. Процесс, 
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который собирается выполнить зідпаі, может оценить необходимость этого дей¬ 
ствия по значениям переменных. 

В листинге 2.7 представлена схема решения проблемы производителя и потре¬ 
бителя с применением мониторов, написанная на воображаемом языке Ріб§іп Разсаі. 
В данной ситуации этот язык удобен своей простотой, а также тем, что он позво¬ 
ляет в точности следовать модели Хоара и Бринча Хансена. В каждый момент вре¬ 
мени активна только одна процедура монитора. Буфер состоит из N сегментов. 

Листинг 2.7. Схема решения проблемы производителя и потребителя 
с применением мониторов 

топИог РгосіисегСопзшіег 

сопсІИіоп ТиП , етріу; 
і поедет соипі; 

ргосесіиге іпзегКИет; Шедег); 

Ьедіп 

И соипГ = N Ытеп иаШРиП): 
іпзегМЬеітКИет); 
соипі := соигтЬ+1; 

И соипі = 1 ЬЬеп зідпаі (ешріу) 

епсі; 

РипсЬіоп гетоѵе: іпредег; 

Ьедіп 

И соипі = 0 ЬЬеп ыаИ(етрІу): 
гетоѵе = гетоѵе_Пет: 
соипі := соипЬ-1: 

И соипі = N-1 ЬЬеп зідпаКРиЛ) 

епсі; 

соипі := 0; 

епсі топИог; 

ргосесіиге ргосіисег; 

Ьедіп 

ыЬЛе Ігие Ьо 
Ьедіп 

Нет = ргоЬисе_Иет; 

РгосіисегСопзитег. іпзегЦ Нет) 

епсі 

епсі; 

ргосесіиге сопзитег; 

Ьедіп 

«Ьііе Ігие сіо 
Ьедіп 

Нет = РгосіисегСопзитег. гетоѵе; 
сопзите_Иет(Иет) 

епсі 

епй: 


Можно подумать, что операции ѵѵаіЬ и зідпаі похожи на зіеер и ѵѵакеир, которые 
приводили к неустранимым состояниям соревнования. Они действительно похожи, 
но с одним существенным отличием: неудачи применения операций зіеер и макеир 
были связаны с тем, что один процесс пытался уйти в состояние ожидания, в то 
время как другой процесс пытался активировать его. С мониторами такого произой¬ 
ти не может. Автоматическое взаимное исключение, реализуемое процедурами 
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монитора, гарантирует: если производитель, находящийся в мониторе, обнаружит 
полный буфер и решит выполнить операцию маИ, можно не опасаться, что плани¬ 
ровщик передаст управление потребителю раньше, чем операция маИ будет завер¬ 
шена. Потребитель даже не сможет попасть в монитор, пока операция маИ не бу¬ 
дет выполнена и производитель не прекратит работу. 

Несмотря на то что Рійфп Разсаі — воображаемый язык, существует несколько 
языков программирования, поддерживающих мониторы, хотя и не всегда в соответ¬ 
ствии с моделью Хоара и Бринча Хансена. Один из таких языков — ^ѵа, объект¬ 
но-ориентированный язык, поддерживающий потоки на уровне пользователя и 
позволяющий группировать методы (процедуры) в классы. Добавление в описание 
метода ключевого слова зупсіігопігесі гарантирует, что если хотя бы один поток на¬ 
чал выполнение этого метода, ни один другой поток не сможет выполнять другой 
синхронизированный (определенный как зупсіпгопігесі) метод из этого класса. 

Решение проблемы производителя и потребителя с использованием монито¬ 
ров, написанное на ^ѵа, представлено в листинге 2.8. Решение состоит из четырех 
классов. Внешний класс, РгосіисегСотитег, создает и запускает два потока, рис. 
Второй и третий классы, ргосіисег и сои.?мтег соответственно, содержат программы 
производителя и потребителя. Класс ои(_топі(ог является монитором. Он содер¬ 
жит два синхронизированных потока, используемых для текущего помещения эле¬ 
ментов в буфер и извлечения их оттуда. В отличие от предыдущих примеров, здесь 
приведен полный текст программ ітегі и гетоѵе. 

Листинг 2.8. Решение проблемы производителя и потребителя на ^ѵа 

риЫіс сіазз РгойисегСопзитег { 

збаііс Гіпаі іпі N = 100; ' // константа, задающая размер буфера 

зіаііс ргосіисег р = пеіѵ ргосІисегО; // создать экземпляр потока производителя 

збабіс сопзитег с = пеіѵ сопзитегО; // создать экземпляр потока потребителя 

збаііс оиг_топіі:ог топ = пек/ оиг_топіІог(): // создать экземпляр монитора 

риЫіс зГабіс ѵоісі таіп(5ігіпд агдз[]) { 

р. збагШ; // запуск потока производителя 

с. зіагЮ: // запуск потока потребителя 


збаііс сіазз ргосіисег ехіепсіз ТГігеасІ { 

риЫіс ѵоісі гип() { // метод тип содержит программу потока 

іпГ ібет; 

и/МІе (бгие) { // цикл производителя 

ііет = ргос!исе_і Тет() : 
топ.іпзегШбет); 


ргіѵаГе іпГ ргос!исе_і1;ет() { ... } // собственно производство 


збаііс сіазз сопзитег ехГепсІз ТбгеасІ { 

риЫіс ѵоісі гип() { // метод гип содержит программу потока 

іпі і Ьет: 

к/ЫІе (Ггие) { // цикл потребителя 

ібет = топ.гетоѵеО: 
сопзите_і1;ет (іГет); 
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ргіѵаіе ѵоіб соп$шіе_іІет(іпІ Нет) { } // собственно потребление 


зіаііс сіазз оигмтюпііог { // монитор 

ргіѵаіе іпі ЬиФФег[] » пем ІггЬСЫ]: 

ргіѵаіе іпі соипі = 0. Іо - 0. Ніз 0: // счетчики и индексы 

риЫіс зупсЬгопігеб ѵоіб іпзегКіпі ѵаі) { 

іФ (соипі == N1 до_Іо_5Іеер(); // если буфер полон, уйти в состояние ожидания 
ЬиФФег [Ьі] = ѵаі; // поместить элемент в буфер 

Иі = (Іті+ІШ: // следующий сегмент, в который будет помещен элемент 

соипі = соипі+і; // теперь в буфере на один элемент больше 

іФ (соипі == 1) поСі "Гу(); // если потребитель в состоянии ожидания, 

активировать его 


риЫіс зупсбгопігесі іпі гегпоѵе( ) { 
іпі ѵаі; 

іФ (соипі == 0) до_1о_з1еер( ); // если буфер пуст, уйти в состояние ожидания 

ѵаі -= ЬиФФег [Іо]: // забрать элемент из буфера 

Іо = (1о+1Ш: // следующий сегмент, из которого заберут элемент 

соипі = соипі -1: // теперь в буфере на один элемент меньше 

іФ (соипі == N -1) поІіФуО: // если производитель в состоянии ожидания, 

активировать его 

геіигп ѵаі : 

} 

ргіѵаіе ѵоіб до_1о_з1еер() { Ігу{ѵгаіК):} саІсИ(1 пІеггирІесІЕхсерІіоп ехс) {};} 

} 

} 

Потоки производителя и потребителя функционально идентичны соответству¬ 
ющим частям программы предыдущих примеров. В программе производителя есть 
бесконечный цикл формирования данных и помещения их в общий буфер. В коде 
потребителя есть бесконечный цикл с изъятием данных из общего буфера и их 
обработкой. 

Интерес для нас представляет класс оиг_топіСог, содержащий буфер, перемен¬ 
ные администрирования и два метода синхронизации. Когда производитель акти¬ 
вен в процедуре іпзегі, потребитель не может быть активным в процедуре гетоѵе , 
что исключает состояние состязания. Переменная соипі отслеживает количество 
элементов в буфере, принимая значения от 0 до N - 1. Переменная Іо является 
индексом следующего сегмента буфера, из которого следует извлечь данные. Пере¬ 
менная кі является индексом следующего сегмента буфера, в который следует 
поместить данные. Разрешена ситуация, в которой /о = кі, что означает 0 или N 
элементов в буфере. Различать эти два случая можно по переменной соипі. 

Синхронизированные методы в языке ^ѵа отличаются от стандартных мони¬ 
торов отсутствием переменных состояния. Взамен предлагаются две процедуры, 
гтіі и поіі/у, которые аналогичны зіеер и к/акеир с той лишь разницей, что они ис¬ 
пользуются в синхронизированных методах, а это исключает состояния состязания. 
Теоретически процедура может быть прервана, для чего и служит весь окружающий 
ее набор программ. }аѵа требует, чтобы исключения обрабатывались явно. В нашем 
случае просто представьте, что §о_1о_з1еер описывает уход в состояние ожидания. 

Благодаря автоматизации взаимного исключения применение мониторов сде¬ 
лало параллельное программирование значительно менее подверженным ошиб¬ 
кам, чем применение семафоров. Но и у мониторов тоже есть свои недостатки. 




146 


Глава 2. Процессы и потоки 


Недаром два примера мониторов, которые мы рассмотрели, были написаны на 
Рісі§іп Разсаі и^ѵа, а не на С, как все остальные примеры этой книги. Как мы уже 
говорили, мониторы являются структурным компонентом языка программиро¬ 
вания, и компилятор должен их распознавать и организовывать взаимное ис¬ 
ключение. В Разсаі, С и многих других языках нет мониторов, поэтому странно 
было бы ожидать от их компиляторов выполнения правил взаимного исключения. 
И в самом деле, как может отличить компилятор процедуры монитора от остальных? 

В этих языках также нет и семафоров, но их легко добавить: нужно всего лишь 
присоединить к библиотеке две короткие программы, написанные на ассемблере 
и реализующие системные вызовы ир и сісмп. Компиляторы при этом не обязаны 
знать об их существовании. Разумеется, операционная система должна знать о се¬ 
мафорах, но даже если у вас операционная система с семафорами, вы можете пи¬ 
сать программы для нее на С или С++ (или на ассемблере, если вы склонны к ма¬ 
зохизму). Если же у вас операционная система с мониторами, вам необходим язык 
со встроенными мониторами. 

Другая проблема, связанная с мониторами и семафорами, состоит в том, что они 
были разработаны для решения задачи взаимного исключения в системе с одним 
или несколькими процессорами, имеющими доступ к общей памяти. Помещение 
семафоров в разделенную память с защитой в виде команд Т51. может исключить 
состояния состязания. Эти примитивы будут неприменимы в распределенной си¬ 
стеме, состоящей из нескольких процессоров с собственной памятью у каждого, 
связанных локальной сетью. Вывод из всего вышесказанного следующий: семафо¬ 
ры являются примитивами слишком низкого уровня, а мониторы могут использо¬ 
ваться только в некоторых языках программирования. Примитивы не подходят и для 
реализации обмена информацией между компьютерами — нужно что-то другое. 

Передача сообщений 

В роли чего-то другого выступает передача сообщений. Этот метод межпроцесс¬ 
ного взаимодействия использует два примитива: зепсі и гесеіѵе, которые скорее 
являются системными вызовами, чем структурными компонентами языка (что 
отличает их от мониторов и делает похожим на семафоры). Поэтому их легко мож¬ 
но поместить в библиотечные процедуры, например 

БепсКсІеБГіпаГіоп. &те55аде); 
гесеіѵе($оигсе, &те55аде); 

Первый запрос посылает сообщение заданному адресату, а второй получает со¬ 
общение от указанного источника (или от любого источника, если это не имеет 
значения). Если сообщения нет, второй запрос блокируется до поступления сооб¬ 
щения либо немедленно возвращает код ошибки. 

Разработка систем передачи сообщений 

С системами передачи сообщений связано большое количество сложных проблем 
и конструктивных вопросов, которых не возникает в случае семафоров и монито¬ 
ров. Особенно много сложностей появляется в случае взаимодействия процессов, 
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происходящих на различных компьютерах, соединенных сетью. Так, сообщение 
может потеряться в сети. Чтобы избежать потери сообщений, отправитель и полу¬ 
чатель договариваются, что при получении сообщения получатель посылает об¬ 
ратно подтверждение приема сообщения. Если отправитель не получает подтвер¬ 
ждения через некоторое время, он отсылает сообщение еще раз. 

Теперь представим, что сообщение получено, но подтверждение до отправите¬ 
ля не дошло. Отправитель пошлет сообщение еще раз, и до получателя оно дойдет 
дважды. Крайне важно, чтобы получатель мог отличить копию предыдущего со¬ 
общения от нового. Обычно проблема решается с помощью помещения порядко¬ 
вого номера сообщения в тело самого сообщения. Если к получателю приходит 
письмо с номером, совпадающим с номером предыдущего письма, письмо клас¬ 
сифицируется как копия и игнорируется. Решение проблемы успешного обмена 
информации в условиях ненадежной передачи сообщений составляет основу изу¬ 
чения компьютерных сетей. Информацию по этой теме можно найти в [323]. 

Для систем обмена сообщениями также важен вопрос названий процессов. Не¬ 
обходимо однозначно определять процесс, указанный в запросе зепсі или гесеіѵе. 
Кроме того, встает вопрос аутентификации: каким образом клиент может опре¬ 
делить, что он взаимодействует с настоящим файловым сервером, а не с само¬ 
званцем? 

Помимо этого, существуют конструктивные проблемы, существенные при рас¬ 
положении отправителя и получателя на одном компьютере. Одной из таких про¬ 
блем является производительность. Копирование сообщений из одного процесса 
в другой происходит гораздо медленнее, чем операция на семафоре или вход в мо¬ 
нитор. Было проведено множество исследований с целью увеличения эффектив¬ 
ности передачи сообщений. В [65], например, предлагалось ограничивать размер 
сообщения до размеров регистра и передавать сообщения через регистры. 

Решение проблемы производителя и потребителя 
с передачей сообщений 

Теперь рассмотрим решение проблемы производителя и потребителя с передачей 
сообщений и без использования разделенной памяти. Решение представлено в лис¬ 
тинге 2.9. Мы предполагаем, что все сообщения имеют одинаковый размер и сооб¬ 
щения, которые посланы, но еще не получены, автоматически помещаются опе¬ 
рационной системой в буфер. В этом решении используются N сообщений, по 
аналогии с N сегментами в буфере. Потребитель начинает с того, что посылает про¬ 
изводителю N пустых сообщений. Как только у производителя оказывается эле¬ 
мент данных, который он может предоставить потребителю, он берет пустое сооб¬ 
щение и отсылает назад полное. Таким образом, общее число сообщений в системе 
постоянно и их можно хранить в заранее заданном участке памяти. 

Если производитель работает быстрее, чем потребитель, все сообщения будут 
ожидать потребителя в заполненном виде. При этом производитель блокируется 
в ожидании пустого сообщения. Если потребитель работает быстрее, ситуация 
инвертируется: все сообщения будут пустыми, а потребитель будет блокирован 
в ожидании полного сообщения. 
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Листинг 2.9. Решение проблемы производителя и потребителя с использованием 
N сообщений 


#йеЛпе N 100 /* количество сегментов в буфере */ 

ѵоісі ргосіисег(ѵоісі) 


іпі ііегп; 
шеззаде ш: 
мНіІе (ТКІІЕ) { 

Нет - ргос1исе_іІеш(); 
гесеіѵе(сопзитег. &т); 
Ьиі 1<1_гпеззаде(&т, і Сет) : 
вепсКсопзитег. &т): 


/* буфер для сообщений */ 

/* сформировать нечто, чтобы заполнить буфер */ 
/* ожидание прибытия пустого сообщения */ 

/* сформировать сообщение для отправки */ 

/* отослать элемент потребителю */ 


ѵоісі сопзишег(ѵоісі) 


іпі Нет. і; 
теззаде т; 

Гог (і - 0; і < N 1 і++) зепсКргосІисег, &т); /* отослать N пустых сообщений */ 

ѵѵГіі 1 е (ТК1ІЕ) { 


гесеіѵе(ргосІисег. &т): 
Нет “ ех1гасб_иет(&т) 
зепсКргосІисег, &т): 
сопзите ііет(ііет): 


/* получить сообщение с элементом */ 
/* извлечь элемент из сообщения */ 

/* отослать пустое сообщение */ 

/* обработка элемента */ 


Передача сообщений может быть реализована по-разному. Рассмотрим способ 
адресации сообщений. Можно присвоить каждому из процессов уникальный 
адрес и адресовать сообщение непосредственно процессам. Другой подход состо¬ 
ит в использовании новой структуры данных, называемой почтовым ящиком. По¬ 
чтовый ящик — это буфер для определенного количества сообщений, тип которых 
задается при создании ящика. При использовании почтовых ящиков в качестве 
параметров адреса зепсі и гесеіѵе задаются почтовые ящики, а не процессы. Если 
процесс пытается послать сообщение в полный почтовый ящик, ему приходится 
подождать, пока хотя бы одно сообщение не будет удалено из ящика. 

В задаче производителя и потребителя оба они создадут почтовые ящики, дос¬ 
таточно большие, чтобы хранить N сообщений. Производитель будет посылать со¬ 
общения с данными в почтовый ящик потребителя, а потребитель будет посылать 
пустые сообщения в почтовый ящик производителя. С использованием почтовых 
ящиков метод буферизации очевиден: в почтовом ящике получателя хранятся со¬ 
общения, которые были посланы процессу-получателю, но еще не получены. 

Другим предельным случаем использования почтовых ящиков является прин¬ 
ципиальное отсутствие буферизации. При таком подходе, если зепсі выполняется 
раньше, чем гесеіѵе, посылающий процесс блокируется до выполнения гесеіѵе, 
когда сообщение может быть напрямую скопировано от отправителя к получате¬ 
лю без промежуточной буферизации. Если гесеіѵе выполняется раньше, чем зепсі, 
получающий процесс блокируется до выполнения зепсі. Этот метод часто называ¬ 
ется рандеву, он легче реализуется, чем схема буферизации сообщений, но менее 
гибок, поскольку отправитель и получатель должны работать в режиме жесткой 
синхронизации. 
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Передача сообщений часто используется в системах с параллельным програм¬ 
мированием. Характерным примером системы передачи сообщений является МРІ 
(Ме55а§е-Ра5зіп§ ІпТегіасе — интерфейс передачи сообщений). Более подробную 
информацию по этому вопросу можно найти в [139, 308]. 

Барьеры 

Последний из рассмотренных нами механизмов синхронизации предназначался 
скорее для групп процессов, нежели для ситуаций с двумя процессами типа про¬ 
изводитель-потребитель. Некоторые приложения делятся на фазы, и существует 
правило, что процесс не может перейти в следующую фазу, пока к этому не готовы 
все остальные процессы. Этого можно добиться, разместив в конце каждой фазы 
барьер. Когда процесс доходит до барьера, он блокируется, пока все процессы не 
дойдут до барьера. Действие барьера представлено на рис. 2.17. 
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Рис. 2.17. Применение барьеров: процессы, приближающиеся к барьеру (а); все процессы, 
кроме одного, блокированы барьером (б); как только последний процесс достигает барьера, 
все процессы переходят в следующую фазу (в) 

На рис. 2.17, а представлены четыре процесса, приближающиеся к барьеру. Это 
означает, что они заняты вычислениями и еще не дошли до конца фазы. Через не¬ 
которое время первый процесс завершает вычисления, предусмотренные в этой 
фазе. Он выполняет примитив Ьаггіег, чаще всего вызывая библиотечную проце¬ 
дуру. Затем процесс приостанавливается. Через некоторое время второй и третий 
процессы заканчивают первую фазу и выполняют примитив Ьаггіег (рис. 2.17, б). 
Наконец, когда последний процесс достигает барьера, все процессы переходят в сле¬ 
дующую фазу, как показано на рис. 2.17, в. 

Рассмотрим типичную задачу релаксации в физике или машиностроении в ка¬ 
честве примера ситуации, требующей наличия барьеров. Обычно задача пред¬ 
ставляется в виде матрицы с некоторыми начальными значениями. Эти значе¬ 
ния могут соответствовать температуре в разных точках металлической пластины. 
Необходимо рассчитать, через какое время установится постоянное распределе¬ 
ние температуры в случае нагрева одной стороны пластины. 

К матрице применяется некоторое преобразование, например соответствующее 
законам термодинамики, чтобы получить матрицу значений температуры через 
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некоторое время. Преобразование применяется снова и снова, чтобы получить за¬ 
висимость температуры в каждой точке от времени. Результатом будет серия мат¬ 
риц, соответствующих различным моментам времени. 

Теперь представим, что матрица очень большая (скажем, миллион на милли¬ 
он) и для ускорения расчетов необходимы параллельные процессы, возможно, на 
мультипроцессоре. Различные процессы обрабатывают различные части матрицы, 
рассчитывая новые элементы на основе старых по законами физики. Очевидно, 
что ни один процесс не должен начинать итерацию п + 1, пока все процессы не за¬ 
кончили свою текущую работу. Этой цели можно достичь, если каждый процесс 
будет выполнять операцию Ьаггіег, закончив свою часть итерации. Когда все про¬ 
цессы закончили работу и новая матрица, являющаяся входными данными для 
следующей итерации, составлена, все процессы одновременно начнут следующую 
итерацию. 


Классические проблемы межпроцессного 
взаимодействия 

Литература по операционным системам содержит множество интересных проблем, 
которые широко обсуждались и анализировались с применением различных ме¬ 
тодов синхронизации. В этом разделе мы рассмотрим три наиболее известные про¬ 
блемы. 

Проблема обедающих философов 

В 1965 году Дейкстра сформулировал и решил проблему синхронизации, назван¬ 
ную им проблемой обедающих философов. С тех пор каждый, кто изобретал еще 
один новый примитив синхронизации, считал своим долгом продемонстрировать 
достоинства нового примитива на примере проблемы обедающих философов. Про¬ 
блему можно сформулировать следующим образом: пять философов сидят за круг¬ 
лым столом, и у каждого есть тарелка со спагетти. Спагетти настолько скользкие, 
что каждому философу нужно две вилки, чтобы с ними управиться. Между каж¬ 
дыми двумя тарелками лежит одна вилка (рис. 2.18). 

Жизнь философа состоит из чередующихся периодов поглощения пищи и раз¬ 
мышлений. (Разумеется, это абстракция, даже применительно к философам, но 
остальные процессы жизнедеятельности для нашей задачи несущественны.) Ког¬ 
да философ голоден, он пытается получить две вилки, левую и правую, в любом 
порядке. Если ему удалось получить две вилки, он некоторое время ест, затем 
кладет вилки обратно и продолжает размышления. Вопрос состоит в следующем: 
можно ли написать алгоритм, который моделирует эти действия для каждого 
философа и никогда не застревает? (Кое-кто считает, что необходимость двух 
вилок выглядит несколько искусственно. Возможно, нам следует заменить италь¬ 
янскую пищу блюдами китайской кухни, спагетти — рисом, а вилки — соответству¬ 
ющими палочками.) 
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Рис. 2.18. Время обеда на факультете философии 


В листинге 2.10 представлено очевидное решение проблемы. Процедура Іаке_ 
/огк ждет, пока указанная вилка не освободится, и берет ее. К сожалению, это ре¬ 
шение неверно — представьте себе, что все пять философов возьмут одновремен¬ 
но свои левые вилки. Каждый останется без правой вилки, и произойдет взаимо¬ 
блокировка. 


Листинг 2.10. Неверное решение проблемы обедающих философов 

#(Міпе N 5 /* Количество философов */ 

ѵоісі рЫ 10505рЬег( 1 гтЬ і) /* і - номер философа, от 0 до 4 */ 


ѵФіІе(ТКІІЕ) { 

ТМпкО; /* Философ размышляет */ 

Таке_Тогк(і ); /* Берет левую вилку */ 

Гаке_Гогк( (і+1) * Ю: /* Берет правую вилку */ 
еаШ: /* Спагетти, ням-ням */ 

риТ_Гогк(і ): /* Кладет на стол левую вилку */ 

риТ_Гогк((і+1) * Ю: /* Кладет на стол правую вилку */ 

} 

> 

Можно изменить программу так, чтобы после получения левой вилки прове¬ 
рялась доступность правой. Если правая вилка недоступна, философ отдает левую 
обратно, ждет некоторое время и повторяет весь процесс. Этот подход также не 
будет работать, хотя и по другой причине. Если не повезет, все пять философов 
могут начать процесс одновременно, взять левую вилку, обнаружить отсутствие 
правой, положить левую обратно на стол, одновременно взять левую вилку, и так 
до бесконечности. Ситуация, в которой все программы продолжают работать сколь 
угодно долго, но не могут добиться хоть какого-то прогресса, называется зависа¬ 
нием процесса (по-английски зІагѵаГіоп, буквально «умирание от голода». Этот 
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термин применяется даже в том случае, когда проблема возникает не в итальян¬ 
ском или китайском ресторане, а на компьютерах). 

Вы можете подумать: «Если философы будут размышлять в течение некоторого 
случайно выбранного промежутка времени после неудачной попытки взять правую 
вилку, вероятность того, что все процессы будут продолжать топтаться на месте 
хотя бы в течение часа, невелика». Это правильно, и для большинства приложений 
повторение попытки спустя некоторое время не является проблемой. Например, 
в локальной сети ЕіЬегпеІ; в ситуации, когда два компьютера посылают пакеты 
одновременно, каждый должен подождать случайно заданное время и повторить 
попытку — на практике это решение хорошо работает. Тем не менее в некоторых 
приложениях предпочтительным является другое решение, работающее всегда 
и не зависящее от случайных чисел (например, в приложении для обеспечения 
безопасности на атомных электростанциях). 

В листинг 2.10 можно внести улучшение, исключающее взаимоблокировку 
и зависание процесса: защитить пять операторов, следующих за запросом ікіпк, 
бинарным семафором. Тогда философ должен будет выполнить операцию сЫп на 
переменной тиіех прежде, чем потянуться к вилкам. А после возврата вилок на 
место ему следует выполнить операцию ир на переменной тиіех. С теоретической 
точки зрения решение вполне подходит. С точки зрения практики возникают про¬ 
блемы с эффективностью: в каждый момент времени может есть спагетти только 
один философ. Но вилок пять, поэтому необходимо разрешить есть в каждый мо¬ 
мент времени двум философам. 

Решение, представленное в листинге 2.11, исключает взаимоблокировку и по¬ 
зволяет реализовать максимально возможный параллелизм для любого числа фи¬ 
лософов. Здесь используется массив зіаіе для отслеживания душевного состояния 
каждого философа: он либо ест, либо размышляет, либо голодает (пытаясь полу¬ 
чить вилки). Философ может начать есть, только если ни один из его соседей не 
ест. Соседи философа с номером і определяются макросами ЬЕРТ и КІСНТ (то есть 
если і = 2, то ЬЕЕТ = 1 и КІСНТ = 3). 


Листинг 2.11 . Решение задачи обедающих философов 


#с1еГіпе N 5 

#с1еГіпе ЬЕРТ (і+Ю)ЭД 

#с!еГі пе КІСНТ (і+1Ш 

#с1еГіпе ТНІШ№ О 

#с1еГіпе НДОВКУ 1 

#сІеГіпе ЕАТІИС 2 

ТуресІеТ і пТ зетарЬоге: 
іпТ зІаІеОТ; 
зетарНоге тиіех = 1; 
зетарНоге зОТ; 


/* Количество философов */ 

/* Номер левого соседа философа с номером і */ 

/* Номер правого соседа философа с номером і */ 

/* Философ размышляет */ 

/* Философ пытается получить вилки */ 

/* Философ ест */ 

/* Семафоры - особый вид целочисленных переменных */ 

/* Массив для отслеживания состояния каждого философа */ 
/* Взаимное исключение для критических областей */ 

/* Каждому философу по семафору */ 


ѵоіб рНі 105орНег( і пТ і) /* і - номер философа, от 0 до N-1 */ 


мМІе (ТКІЮ { 
ІМпк( ): 
іаке_Гогкз(і): 
еаІО; 

риТ_Гогк5(і): 


/* Повторять до бесконечности */ 

/* Философ размышляет */ 

/* Получает две вилки или блокируется */ 
/* Спагетти, ням-ням */ 

/* Кладет на стол обе вилки */ 
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ѵоіб іаке_бэгк5(ііи 1) 


/* і - номер философа, от 0 до N-1*/ 


бомп(&ішЕех) ; 
5Іа-Ье[і ] = НиЫОКУ: 
ТезШ): 
ир(&тиЕех): 
боѵѵп(&$[і]) ; 


/* Вход в критическую область */ 

/* Фиксация наличия голодного философа */ 
/* Попытка получить две вилки */ 

/* Выход из критической области */ 

/* Блокировка, если вилок не досталось */ 


ѵоісі ри1:_-Гогк$(і ) 


/* і - номер философа, от 0 до N-1*/ 


боміК&тибех) : 
збабеСі] = ТНШШ6: 
ИезКБЕРТ): 
ЕезШШНТ): 
ир(&ти(:ех); 


/* Вход в критическую область */ 

/* Философ перестал есть */ 

/* Проверить, может ли есть сосед слева */ 
/* Проверить, может ли есть сосед справа */ 
/* Выход из критической области */ 


ѵоісі Те$Ш) /* і - номер философа, от 0 до N-1*/ 

{ 

іб ЫабеШ “ ШОКУ && зтеДЕРТ] != ЕАТШС && зТаТеСКіент] != ЕАШО) { 
зТаТеШ = ЕАТІ N0: 
ир(&з[і]): 


В программе используется массив семафоров, по одному на философа, чтобы 
блокировать голодных философов, если их вилки заняты. Обратите внимание, что 
каждый процесс запускает процедуру ркііозоркег в качестве своей основной про¬ 
граммы, но остальные процедуры Іаке _[огкз, риі _[огкх и іе.хі являются обычными 
процедурами, а не отдельными процессами. 


Проблема читателей и писателей 

Проблема обедающих философов полезна для моделирования процессов, сорев¬ 
нующихся за монопольный доступ к ограниченному количеству ресурсов, напри¬ 
мер к устройствам ввода-вывода. Другой известной задачей является проблема 
читателей и писателей [78], моделирующая доступ к базе данных. Представьте себе 
базу данных бронирования билетов на самолет, к которой пытается получить дос¬ 
туп множество процессов. Можно разрешить одновременное считывание данных 
из базы, но если процесс записывает информацию в базу, доступ остальных про¬ 
цессов должен быть прекращен, даже доступ на чтение. Как запрограммировать 
читателей и писателей? Одно из решений представлено в листинге 2.12. 


Листинг 2.12. Решение проблемы читателей и писателей 


ТуребеГ іпб зетарЬоге: 
зешарЬоге тыбех = 1: 
зетарНоге 6Ь = 1: 
іпб гс = 0: 


/* Воспользуйтесь своим воображением */ 

/* Контроль доступа к гс */ 

/* Контроль доступа к базе данных */ 

/* Количество процессов, читающих или желающих читать */ 


ѵоіб геабег(ѵоіб) 


продолжение & 
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/* Повторять до бесконечности */ 

/* Получение монопольного доступа к гс */ 

/* Одним читающим процессом больше */ 

/* Если этот читающий процесс - первый... */ 

/* Отказ от монопольного доступа к гс */ 

/* Доступ к данным */ 

/* Получение монопольного доступа к гс */ 

/* Одним читающим процессом меньше */ 

/* Если этот читающий процесс - последний... */ 
/* Отказ от монопольного доступа к гс */ 

/* Вне критической области */ 


Листинг 2.12 ( продолжение) 
мНіІе (ТРОЕ) { 
сЫгЦ&шТех); 
гс = гс+1: 

ІГ (гс == 1) сіоѵѵпС&сіЬ) : 
ирС&тыТех): 
геасІсІаѣаЬазеС ); 
сЫпС&тыТех) : 
гс = гс-1: 

іГ (гс == 0) ирШЬ): 
ир(&тиі:ех): 
и$е_сІа1:а_геасІ(); 

} 

} 

ѵоісі и/гібег(ѵоісІ) 

{ 

мНіІе (ТРОЕ) { 
ТІгіпк_ир_сіа1:а(): 
бшп(&сІЬ): 
іл/гіІе_сіа1:а_Ьа5е(); 
ир(&сІЬ): 


/* Повторять до бесконечности */ 

/* Вне критической области */ 

/* Получение монопольного доступа */ 
/* Запись данных */ 

/* Отказ от монопольного доступа */ 


Первый читающий процесс выполняет операцию сіомп на семафоре <ІЪ, чтобы 
получить доступ к базе. Последующие читатели просто увеличивают значение 
счетчика гс. По мере ухода читателей из базы значение счетчика уменьшается, 
и последний читающий процесс выполняет на семафоре <1Ъ операцию ир, позволяя 
блокированному пишущему процессу получить доступ к базе. 

В этом решении один момент требует комментариев. Представьте, что в то вре¬ 
мя как один читатель уже пользуется базой, другой читатель запрашивает доступ 
к базе. Доступ разрешается, поскольку читающие процессы друг другу не мешают. 
Доступ разрешается и третьему, и последующим читателям. 

Затем доступ запрашивает пишущий процесс. Запрос отклонен, поскольку пи¬ 
шущим процессам необходим монопольный доступ, и пишущий процесс приоста¬ 
навливается. Пока в базе есть хотя бы один активный читающий процесс, доступ 
остальным читателям разрешается, а они все приходят и приходят. Если, предпо¬ 
ложим, новый читающий процесс запрашивает доступ каждые 2 с, а провести в базе 
ему надо 5 с, то пишущий процесс никогда в базу не попадет. 

Чтобы избежать такой ситуации, нужно немного изменить программу: если 
пишущий процесс ждет доступа к базе, новый читающий процесс доступа не по¬ 
лучает, а становится в очередь за пишущим процессом. Теперь пишущему процес¬ 
су нужно подождать, пока базу покинут уже находящиеся в ней читающие про¬ 
цессы, но не нужно пропускать вперед читающие процессы, пришедшие к базе 
после него. Недостаток этого решения заключается в снижении производительно¬ 
сти, вызванном уменьшением конкуренции. В [78] представлено решение, в кото¬ 
ром пишущим процессам предоставляется более высокий приоритет. 
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Проблема спящего брадобрея 

Действие еще одной классической проблемной ситуации межпроцессного взаимо¬ 
действия разворачивается в парикмахерской. В парикмахерской есть один брадоб¬ 
рей, его кресло и п стульев для посетителей. Если желающих воспользоваться его 
услугами нет, брадобрей сидит в своем кресле и спит (рис. 2.19). Если в парикма¬ 
херскую приходит клиент, он должен разбудить брадобрея. Если клиент приходит 
и видит, что брадобрей занят, он либо садится на стул (если есть место), либо 
уходит (если места нет). Необходимо запрограммировать брадобрея и посетите¬ 
лей так, чтобы избежать состояния состязания. У этой задачи существует много 
аналогов в сфере массового обслуживания, например информационная служба, 
обрабатывающая одновременно ограниченное количество запросов, с компью¬ 
теризированной системой ожидания для запросов. 



Рис. 2.19. Спящий брадобрей 

В предлагаемом решении используются три семафора: сизіотегз, для подсчета 
ожидающих посетителей (клиент, сидящий в кресле брадобрея, не учитывается — 
он уже не ждет); ЬагЬегз, количество брадобреев (0 или 1), простаивающих в ожи¬ 
дании клиента, и тиіех для реализации взаимного исключения. Также использу¬ 
ется переменная тюаіііщ, предназначенная для подсчета ожидающих посетителей. 
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Она является копией переменной сизіотегз. Присутствие в программе этой пере¬ 
менной связано с тем фактом, что прочитать текущее значение семафора невоз¬ 
можно. В этом решении посетитель, заглядывающий в парикмахерскую, должен 
сосчитать количество ожидающих посетителей. Если посетителей меньше, чем 
стульев, новый посетитель остается, в противном случае он уходит. 

Решение представлено в листинге 2.13. Когда брадобрей приходит утром на 
работу, он выполняет процедуру ЬагЬег, блокируясь на семафоре сизіотегз, посколь¬ 
ку значение семафора равно 0. Затем брадобрей засыпает, как показано на рис. 2.19, 
и спит, пока не придет первый клиент. 


Листинг 2.13. Решение проблемы спящего брадобрея 

#сІеГіпе СНАІК5 5 /* Количество стульев для посетителей */ 


ГуресІеГ іпЕ зетарбоге; 


/* Догадайтесь сами */ 


зетарбоге сызіотегз = 0; 
зетарИоге ЬагЬегз = 0; 
зешарИоге тиіех = 1: 
іпі маіііпд = 0; 


/* Количество ожидающих посетителей */ 

/* Количество брадобреев, ждущих клиентов */ 
/* Для взаимного исключения */ 

/* Ожидающие (не обслуживаемые) посетители */ 


ѵоісі ЬагЬег(ѵоіб) 

{ 

мИПе (ТКІІЕ) { 

бомп(&си$1отег$); 
сЫп(&тіЛех) ; 
маіііпд = маіііпд - 1: 
ир(&ЬагЬегз): 
ир(&тиІех); 
сиі ИаігО: 


/* Если посетителей нет. уйти в состояние ожидания */ 
/* Запрос доступа к шіЕіпд */ 

/* Уменьшение числа ожидающих посетителей */ 

/* Один брадобрей готов к работе */ 

/* Отказ от доступа к маШпд */ 

/* Клиента обслуживают (вне критической области)*/ 


} 


ѵоісі сизЕотег(ѵоісІ) 

{ 

бомп(&тибех); 

1Г (маіЕіпд < СНАІК5) { 
маібіпд = маібіпд + 1: 
ир(&сизСотегз); 
ир(&тиЕех); 
Домп(&ЬагЬег5); 
деІ_ІгаігсиШ; 

} еізе { 

ир(&тиІех): 


/* Вход в критическую область */ 

/* Если свободных стульев нет, придется уйти */ 

/* Увеличение числа ожидающих посетителей */ 

/* При необходимости, разбудить брадобрея */ 

/* Отказ от доступа к маіЕіпд */ 

/* Если брадобрей занят, уйти в состояние ожидания */ 

/* Клиента усаживают и обслуживают */ 

/* Много посетителей, из парикмахерской придется уйти */ 


Приходя в парикмахерскую, посетитель выполняет процедуру сихіотег, запра¬ 
шивая доступ к тиіех для входа в критическую область. Если вслед за ним появит¬ 
ся еще один посетитель, ему не удастся что-либо сделать, пока первый посетитель 
не освободит доступ к тиіех. Затем посетитель проверяет наличие свободных сту¬ 
льев, в случае неудачи освобождает доступ к тиіех и уходит. 

Если свободный стул есть, посетитель увеличивает значение целочисленной 
переменной іюаіііп §. Затем он выполняет процедуру ир на семафоре си$іотег$, тем 
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самым активизируя поток брадобрея. В этот момент оба — посетитель и брадоб¬ 
рей — активны. Когда посетитель освобождает доступ к тиіех, брадобрей захваты¬ 
вает его, проделывает некоторые служебные операции и начинает стричь клиента. 

По окончании стрижки посетитель выходит из процедуры и покидает парик¬ 
махерскую. В отличие от предыдущих программ, цикла посетителя нет, поскольку 
каждого посетителя стригут только один раз. Цикл брадобрея существует, и бра¬ 
добрей пытается найти следующего посетителя. Если ему это удается, он стрижет 
следующего посетителя, в противном случае брадобрей засыпает. 

Стоит отметить, что, несмотря на отсутствие передачи данных в проблеме чи¬ 
тателей и писателей и в проблеме спящего брадобрея, обе эти проблемы относятся 
к проблемам межпроцессного взаимодействия, поскольку требуют синхронизации 
нескольких процессов. 


Планирование 

Когда компьютер работает в многозадачном режиме, на нем могут быть активны¬ 
ми несколько процессов, пытающихся одновременно получить доступ к процес¬ 
сору. Эта ситуация возникает при наличии двух и более процессов в состоянии 
готовности. Если доступен только один процессор, необходимо выбирать между 
процессами. Отвечающая за это часть операционной системы называется плани¬ 
ровщиком, а используемый алгоритм — алгоритмом планирования. Рассмотрению 
задач, связанных с планированием, посвящены следующие разделы. 

Многие методы, применимые к планированию процессов, также могут быть 
применены к планированию потоков, хотя и не все. Для начала мы остановимся 
на планировании процессов, а позже рассмотрим планирование потоков. 

Введение в планирование 

Давным-давно, во времена систем пакетной обработки, использовавших отобра¬ 
жение содержимого перфокарт на магнитной ленте в качестве устройства ввода, 
алгоритм планирования был прост: запустить следующую задачу на ленте. С появ¬ 
лением систем с разделением времени алгоритм планирования усложнился, посколь¬ 
ку теперь несколько задач одновременно ожидали обслуживания. На некоторых 
мэйнфреймах до сих пор совмещаются системы пакетной обработки и службы раз¬ 
деления времени. В результате планировщик должен решать, запустить ли следу¬ 
ющим пакетное задание или предоставить процессор интерактивному пользова¬ 
телю за терминалом. (Пакетное задание может предполагать запуск нескольких 
последовательных программ за один сеанс, но в этом разделе мы считаем, что па¬ 
кетное задание является запросом на запуск одной программы.) Поскольку время 
процессора является в такой системе дефицитным ресурсом, хороший планиров¬ 
щик может существенно изменить ощущаемую пользователем производитель¬ 
ность работы и, следовательно, степень удовлетворения пользователя. Поэтому 
много усилий было потрачено на разработку умных и эффективных алгоритмов 
планирования. 
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С появлением персональных компьютеров ситуация изменилась. Во-первых, 
большую часть времени активен только один процесс. Пользователь, работающий 
с документом в текстовом редакторе, вряд ли будет одновременно считать что-либо 
в фоновом режиме. Когда пользователь дает команду текстовому процессору, пла¬ 
нировщику не приходится долго выбирать, какой процесс запустить, поскольку 
других кандидатов нет. 

Во-вторых, компьютеры стали настолько быстрее, что время процессора прак¬ 
тически перестало быть дефицитным ресурсом. Большинство программ для пер¬ 
сонального компьютера ограничены скоростью, с которой пользователь вводит 
входные данные (с клавиатуры или с помощью мыши), а не скоростью процессо¬ 
ра. Даже процедуры компиляции, основные потребители процессорного времени 
прошлого, теперь занимают всего несколько секунд. Если одновременно запуще¬ 
ны две программы, например текстовый редактор и электронная таблица, и то вряд 
ли имеет значение, которая из них была первой, поскольку пользователь, вероят¬ 
но, ждет окончания работы обеих. Таким образом, на простых персональных ком¬ 
пьютерах планирование не играет существенной роли. Разумеется, существуют 
приложения, занимающие практически весь процессор: визуализация одного часа 
видеозаписи может потребовать обрабатывающих мощностей промышленного 
уровня для всех 108 000 кадров формата ВГГ5С (90 000 кадров формата РАБ), но 
подобные приложения являются скорее исключением из правила. 

Картина меняется при рассмотрении мощных сетевых рабочих станций и сер¬ 
веров. Здесь планирование снова играет существенную роль, поскольку несколь¬ 
ко процессов пытаются получить доступ к процессору. Например, когда процес¬ 
сору нужно выбрать между процессом, перерисовывающим экран после того, как 
пользователь закрыл окно приложения, и процессом, отсылающим почту, впечат¬ 
ление пользователя о реакции компьютера будет существенно зависеть от этого 
выбора. Ведь если перерисовка экрана во время отправки почты займет 2 с, пользо¬ 
ватель решит, что система очень медленная, тогда как двухсекундная отсылка по¬ 
чты даже не будет замечена. В этом случае планирование процессов очень важно. 

Помимо правильного выбора следующего процесса, планировщик также дол¬ 
жен заботиться об эффективном использовании процессора, поскольку переклю¬ 
чение между процессами требует затрат. Во-первых, необходимо переключиться 
из режима пользователя в режим ядра. Затем следует сохранить состояние теку¬ 
щего процесса, включая сохранение регистров в таблице процессов, чтобы их мож¬ 
но было загрузить заново позже. В большинстве систем также необходимо сохра¬ 
нить карту памяти (то есть биты-признаки обращения к страницам памяти). Затем 
нужно выбрать следующий процесс, запустив алгоритм планирования. После это¬ 
го необходимо перезапустить блок управления памятью с картой памяти нового 
процесса. И наконец, нужно запустить новый процесс. Помимо этого, переключе¬ 
ние между процессами обычно делает бесполезной информацию, содержащуюся 
в кэше памяти, что приводит к двойной перезагрузке кэша из основной памяти 
(при входе в ядро и при выходе из ядра). Все это занимает много процессорного 
времени, особенно при слишком частом переключении между процессами, поэто¬ 
му в этом рекомендуется соблюдать умеренность. 
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Поведение процесса 

Практически все процессы чередуют периоды вычислений с операциями (диско¬ 
выми) ввода-вывода, как показано на рис. 2,20. Обычно процессор некоторое время 
работает без остановки, затем происходит системный вызов на чтение из файла или 
запись в файл. После выполнения системного вызова процессор опять считает, 
пока ему не понадобятся новые данные или не потребуется записать полученные 
данные и т. д. Заметьте, что некоторые операции ввода-вывода считаются вычис¬ 
лениями. Например, когда процессор копирует биты в видео-ОЗУ, чтобы перери¬ 
совать экран, он вычисляет, а не выполняет операцию ввода-вывода, поскольку 
задействован процессор. С этой точки зрения операция ввода-вывода выполняется 
в случае, если процесс входит в состояние блокировки, ожидая окончания работы 
внешнего устройства. 




Рис. 2.20. Периоды использования процессора, чередующиеся с ожиданием ввода-вывода: 
процесс, ограниченный возможностями процессора (а); процесс, ограниченный 
возможностями устройств ввода-вывода (б) 


Важно отметить, что некоторые процессы, как на рис. 2.20, а, большую часть 
времени заняты вычислениями, а другие, как на рис. 2.20, б, большую часть време¬ 
ни ожидают ввода-вывода. Первые называются ограниченными возможностями 
процессора, вторые — ограниченными возможностями устройств ввода-вывода. 
Процессы, ограниченные возможностями процессора, обычно характеризуются 
длительными периодами использования процессора и нечастыми ожиданиями вво¬ 
да-вывода, тогда как процессы, ограниченные возможностями устройств ввода- 
вывода, наоборот: короткими периодами использования процессора и частыми 
ожиданиями ввода-вывода. Основным параметром здесь является не время ожи¬ 
дания, а время вычислений. Процессы, ограниченные возможностями устройств 
ввода-вывода, называются так, поскольку загруженность процессора вычислени¬ 
ями между запросами ввода-вывода мала, а не потому, что время выполнения вво¬ 
да-вывода особо велико. На считывание блока данных с диска уходит одно и то же 
время, не зависящее от времени, затрачиваемого на обработку этих данных. 

Стоит отметить, что с увеличением скорости процессоров процессы становятся 
все более ограниченными возможностями устройств ввода-вывода. Это связано 
с тем, что процессоры совершенствуются существенно быстрее, чем диски. Таким 
образом, планирование процессов, ограниченных возможностями устройств вво- 
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да-вывода, будет иметь большее значение в будущем. В таких процессах следует 
избегать простоя относительно медленных дисков. 

Когда планировать? 

Ключевым вопросом планирования является выбор момента принятия решений. 
Оказывается, существует множество ситуаций, в которых необходимо планирова¬ 
ние. Во-первых, когда создается новый процесс, необходимо решить, какой процесс 
запустить: родительский или дочерний. Поскольку оба процесса находятся в состо¬ 
янии готовности, эта ситуация не выходит за рамки обычного и планировщик мо¬ 
жет запустить любой из двух процессов. 

Во-вторых, планирование необходимо, когда процесс завершает работу. Этот 
процесс уже не существует, следовательно, необходимо из набора готовых процес¬ 
сов выбрать и запустить следующий. Если процессов, находящихся в состоянии 
готовности, нет, обычно запускается холостой процесс, поставляемый системой. 

В-третьих, когда процесс блокируется на операции ввода-вывода, семафоре, 
или по какой-либо другой причине, необходимо выбрать и запустить другой про¬ 
цесс. Иногда причина блокировки может повлиять на выбор. Например, если А — 
важный процесс и он ожидает выхода процесса В из критической области, можно 
запустить следующим процесс В, чтобы он вышел из критической области и позво¬ 
лил процессу Л продолжать работу. Сложность, однако, в том, что планировщик 
обычно не обладает информацией, необходимой для принятия правильного решения. 

В-четвертых, необходимость планирования может возникнуть при появлении 
прерывания ввода-вывода. Если прерывание пришло от устройства ввода-вывода, 
закончившего работу, можно запустить процесс, который был блокирован в ожида¬ 
нии этого события. Планировщик должен выбрать, какой процесс запустить: но¬ 
вый, тот, который был остановлен прерыванием, или какой-то другой. 

Если аппаратный таймер выполняет периодические прерывания с частотой 
50 Гц, 60 Гц или с любой другой частотой, решения планирования могут прини¬ 
маться при каждом прерывании по таймеру или при каждом к-и прерывании. Ал¬ 
горитмы планирования можно разделить на две категории согласно их поведению 
после прерываний. Алгоритмы планирования без переключений, иногда называ¬ 
емого также неприоритетным планированием, выбирают процесс и позволяют ему 
работать вплоть до блокировки (в ожидании ввода-вывода или другого процесса), 
либо вплоть до того момента, когда процесс сам не отдаст процессор. Процесс не 
будет прерван, даже если он работает часами. Соответственно, решения планиро¬ 
вания не принимаются по прерываниям от таймера. После обработки прерывания 
таймера управление всегда возвращается приостановленному процессу. 

Напротив, алгоритмы планирования с переключениями, называемого также 
приоритетным планированием, выбирают процесс и позволяют ему работать не¬ 
которое максимально возможное фиксированное время. Если к концу заданного 
интервала времени процесс все еще работает, он приостанавливается и управле¬ 
ние переходит к другому процессу (если в очереди есть процесс). Приоритетное 
планирование требует прерываний по таймеру, происходящих в конце отведенно¬ 
го периода времени, чтобы передать управление планировщику. При отсутствии 
таймера возможно только планирование без переключений. 
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Категории алгоритмов планирования 

В различных средах требуются различные алгоритмы планирования. Это связано 
с тем, что различные операционные системы и различные приложения ориенти¬ 
рованы на разные задачи. Другими словами, то, для чего следует оптимизировать 
планировщик, различно в разных системах. Можно выделить три среды: 

1. Системы пакетной обработки данных. 

2. Интерактивные системы. 

3. Системы реального времени. 

В системах пакетной обработки нет пользователей, сидящих за терминалами и 
ожидающих ответа. В таких системах приемлемы алгоритмы без переключений 
или с переключениями, но с большим временем, отводимым каждому процессу. 
Такой метод уменьшает количество переключений между процессами и улучшает 
эффективность. 

В интерактивных системах необходимы алгоритмы планирования с переклю¬ 
чениями, чтобы предотвратить захват процессора одним процессом. Даже если ни 
один процесс не захватывает процессор на неопределенно долгий срок намеренно, 
из-за ошибки в программе один процесс может заблокировать остальные. Для ис¬ 
ключения подобных ситуаций используется планирование с переключениями. 

В системах с ограничениями реального времени приоритетность, как это ни стран¬ 
но, не всегда обязательна, поскольку процессы знают, что их время ограничено, и бы¬ 
стро выполняют работу, а затем блокируются. Отличие от интерактивных систем 
в том, что в системах реального времени работают только программы, предназна¬ 
ченные для содействия конкретным приложениям. Интерактивные системы явля¬ 
ются универсальными системами. В них могут работать произвольные программы, 
не сотрудничающие друг с другом и даже враждебные по отношению друг к другу. 

Задачи алгоритмов планирования 

Чтобы разработать алгоритм планирования, необходимо иметь представление о том, 
что должен делать хороший алгоритм. Некоторые задачи зависят от среды (системы 
пакетной обработки, интерактивные или реального времени), но есть задачи, одина¬ 
ковые во всех системах. Список задач представлен в табл. 2.5. Мы рассмотрим их ниже. 

Таблица 2.5. Некоторые задачи алгоритмов планирования 
Все системы 

Справедливость — предоставление каждому процессу справедливой доли процессорного 
времени 

Принудительное применение политики — контроль за выполнением принятой политики 
Баланс — поддержка занятости всех частей системы 

Системы пакетной обработки данных 

Пропускная способность — максимальное количество задач в час 

Оборотное время — минимизация времени, затрачиваемого на ожидание обслуживания 
и обработку задачи 

Использование процессора — поддержка постоянной занятости процессора 

Интерактивные системы 

Время отклика — быстрая реакция на запросы 
Соразмерность — выполнение пожеланий пользователя 

Системы реального времени 

Окончание работы к сроку — предотвращение потери данных 

Предсказуемость — предотвращение деградации качества в мультимедийных системах 
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При всех обстоятельствах необходимо справедливое распределение процессор¬ 
ного времени. Сопоставимые процессы должны получать сопоставимое обслужи¬ 
вание. Выделить одному процессу намного больше времени процессора, чем дру¬ 
гому, эквивалентному, несправедливо. Разумеется, с различными категориями 
процессов можно обращаться весьма по-разному. Возьмите, например, задачи обес¬ 
печения безопасности и начисления заработной платы в компьютерном центре 
атомной электростанции. 

С принципом справедливости в какой-то мере связано принудительное приме¬ 
нение системной политики. Если локальная политика заключается в предостав¬ 
лении процессора процессам контроля безопасности по первому требованию, пла¬ 
нировщик должен удостовериться в принудительном применении этой политики, 
даже когда это приводит к начислению заработной платы на 30 с позже. 

Еще одной глобальной задачей является контроль занятости всех частей сис¬ 
темы. Если устройства ввода-вывода и процессор все время работают, в единицу 
времени окажется выполнено гораздо больше полезной деятельности, чем если 
отдельные компоненты будут простаивать. Например, в системах пакетной обра¬ 
ботки планировщик выбирает, какие задачи загрузить в память для работы. Гораз¬ 
до лучше иметь в памяти одновременно несколько процессов, ограниченных воз¬ 
можностями процессора, и несколько процессов, ограниченных возможностями 
устройств ввода-вывода, чем сначала загрузить и запустить несколько процессов, 
ограниченных возможностями процессора, и только потом несколько процессов, 
ограниченных возможностями устройств ввода-вывода. В последнем случае во 
время работы процессов, ограниченных возможностями процессора, будет проста¬ 
ивать диск, а во время работы процессов, ограниченных возможностями устройств 
ввода-вывода, будет простаивать процессор. Правильнее будет заставить работать 
всю систему, аккуратно перемешав процессы. 

Руководители крупных компьютерных центров, в которых обрабатываются 
большие пакетные задания, обычно контролируют три показателя, позволяющие 
оценить эффективность системы: пропускную способность, оборотное время и ис¬ 
пользование процессора. Пропускной способностью называется число выполнен¬ 
ных системой задач в час. В любом случае 50 задач в час лучше, чем 40 задач в час. 
Оборотное время — статистически усредненное время от момента получения за¬ 
дачи до ее выполнения. Оно характеризует время, которое среднестатистический 
пользователь должен ждать получения выходных данных. Основным правилом 
является «чем меньше, тем лучше». 

Алгоритм планирования, максимизирующий пропускную способность, не обя¬ 
зательно минимизирует оборотное время. При наличии смеси из длинных и корот¬ 
ких задач алгоритм, запускающий только короткие задачи, может добиться высо¬ 
кой пропускной способности (много коротких задач в час), но За счет ужасного 
оборотного времени для длинных задач. Если короткие задачи поступают с посто¬ 
янной скоростью, до длинных задач дело может не дойти никогда, в результате чего 
оборотное время будет бесконечным при высокой пропускной способности. 

Учет такой характеристики, как использование процессора, связан с тем, что 
процессор все еще является самой дорогой частью мэйнфреймов, на которых ис¬ 
пользуются системы пакетной обработки. Руководители таких центров чувству¬ 
ют себя неловко, если процессор не занят все время. Хотя на самом деле этот пока¬ 
затель не так уж и важен. Гораздо важнее пропускная способность и оборотное 
время. Рассматривать коэффициент использования процессора в качестве пока- 
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зателя эффективности примерно так же разумно, как рассматривать рейтинг ма¬ 
шин, основанный на количестве оборотов двигателя в минуту. 

Для интерактивных систем, особенно систем и серверов, работающих в режи¬ 
ме разделения времени, важны другие задачи. Самой важной является минимиза¬ 
ция времени отклика, то есть времени между введением команды и получением 
результата. На персональном компьютере с фоновым процессом (например, отправ¬ 
кой и получением почты) запрос пользователя на запуск программы или открытие 
файла должен иметь приоритет перед фоновым процессом. Первоочередная обра¬ 
ботка всех интерактивных запросов рассматривается как хорошее обслуживание. 

Еще одной задачей является достижение соразмерности. У пользователя все¬ 
гда есть собственное (зачастую неправильное) представление о том, сколько време¬ 
ни должна занимать та или иная операция. Если запрос, оцениваемый пользовате¬ 
лем как сложный, занимает много времени, пользователь готов с этим согласиться, 
но если запрос оценивался как простой, пользователь сердится. Так, если после 
щелчка на значке соединения с Интернет-провайдером, у которого аналоговый 
модем, до момента выхода в Интернет проходит 45 с, пользователь воспринимает 
это как должное. Но если 45 с будет занимать отключение от сети, пользователь 
через 30 с начнет безостановочно ругаться, а к 45-й секунде у него пойдет пена изо 
рта. Такое поведение пользователя основано на его представлении о том, что зво¬ 
нок по телефону и установление соединения должно занимать существенно боль¬ 
ше времени, чем разрыв соединения. В некоторых случаях (и в этом тоже) плани¬ 
ровщик не может ничего сделать, но может улучшить ситуацию во многих других, 
особенно если задержка вызвана неправильным порядком процессов. 

Системы реального времени обладают другими свойствами, чем интерактив¬ 
ные системы, соответственно и задачи планирования будут разными. Характерной 
особенностью систем реального времени является наличие жестких сроков вы¬ 
полнения определенных действий. Например, если компьютер управляет устрой¬ 
ством, выдающим данные с постоянной скоростью, неспособность своевременно 
запустить процесс, обрабатывающий данные, приведет к потере данных. Поэтому 
первоочередной задачей в системах реального времени является строгое соблюде¬ 
ние всех (или большинства) требований по срокам. 

В некоторых системах реального времени, особенно связанных с мультимедиа, 
важна предсказуемость. Небольшая временная задержка не является катастрофич¬ 
ной, но неравномерность аудиопроцесса тут же скажется на ухудшении качества 
звука. Это касается и изображения, но слух более чувствителен к вибрации, чем 
зрение. Чтобы исключить эту проблему, планирование процессов необходимо сде¬ 
лать предсказуемым и регулярным. Мы рассмотрим в этой главе алгоритмы пла¬ 
нирования для систем пакетной обработки и интерактивных систем, но рассмот¬ 
рение планирования в системах реального времени отложим до главы 7, в которой 
изучим мультимедийные операционные системы. 

Планирование в системах пакетной 
обработки данных 

Перейдем от общих проблем планирования к конкретным алгоритмам. В этом па¬ 
раграфе мы рассмотрим алгоритмы, используемые в системах пакетной обработ¬ 
ки, а в дальнейших параграфах обратимся к алгоритмам интерактивных систем 
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и систем реального времени. Следует отметить, что некоторые алгоритмы исполь¬ 
зуются как в системах пакетной обработки, так и в интерактивных системах — мы 
рассмотрим их позже. В этом параграфе мы ограничимся алгоритмами планиро¬ 
вания, подходящими только для систем пакетной обработки. 

«Первым пришел — первым обслужен» 

Алгоритм без переключений «первым пришел — первым обслужен» является, по¬ 
жалуй, самым простым из алгоритмов планирования. Процессам предоставляется 
доступ к процессору в том порядке, в котором они его запрашивают. Чаще всего 
формируется единая очередь ждущих процессов. Как только появляется первая 
задача, она немедленно запускается и работает столько, сколько необходимо. 
Остальные задачи ставятся в конец очереди. Когда текущий процесс блокируется, 
запускается следующий в очереди, а когда блокировка снимается, процесс попа¬ 
дает в конец очереди. 

Основным преимуществом этого алгоритма является то, что его легко понять 
и столь же легко программировать. Он справедлив в том же самом смысле, в ка¬ 
ком справедливо распределение дефицитных билетов на концерт или соревнова¬ 
ния среди всех желающих стоять в очереди с двух часов ночи. В этом алгоритме 
все процессы в состоянии готовности контролируются одним связным списком. 
Чтобы выбрать процесс для запуска, нужно всего лишь взять первый элемент спис¬ 
ка и удалить его. Появление нового процесса приводит к помещению его в конец 
списка — что может быть проще? 

К сожалению, у этого алгоритма есть существенный недостаток. Представьте 
себе, что есть один процесс, ограниченный возможностями процессора, который 
каждый раз работает ровно 1 с, и много процессов, ограниченных возможностями 
устройств ввода-вывода, каждый из которых очень в небольшой мере использует 
процессор, но должен выполнить 1000 обращений к диску. Процесс, ограничен¬ 
ный возможностями процессора, запускается, работает 1 с, затем читает блок с 
диска. Теперь запускаются все процессы ввода-вывода и считывают информацию 
с диска. Когда процесс, ограниченный возможностями процессора, получает свой 
блок с диска, он запускается еще на 1 с, а за ним все процессы, ограниченные воз¬ 
можностями устройств ввода-вывода. 

Конечный результат будет следующим: каждый из процессов, ограниченных 
возможностями устройств ввода-вывода, считывает 1 блок данных в секунду, и им 
потребуется по 1000 с, чтобы закончить работу. Если алгоритм планирования 
будет прерывать процесс, ограниченный возможностями процессора, раз в 10 мс, 
процессы, ограниченные возможностями устройств ввода-вывода, закончат за 10 с 
вместо 1000 с и не очень замедлят работу процесса, ограниченного возможностя¬ 
ми процессора. 

«Кратчайшая задача — первая» 

Рассмотрим еще один алгоритм без переключений для систем пакетной обработ¬ 
ки, предполагающий, что временные отрезки работы известны заранее. Например, 
работники страховой компании могут довольно точно предсказать, сколько вре¬ 
мени займет обработка пакета из 1000 исков, поскольку они делают это каждый 
день. Если в очереди есть несколько одинаково важных задач, планировщик выби- 
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рает первой самую короткую задачу. Посмотрите на рис. 2.21. У нас есть четыре 
задачи: А, В, С и Д со временем выполнения 8, 4, 4 и 4 мин соответственно. Если 
мы запустим их в данном порядке, оборотное время задачи А будет 8 мин, В — 
12 мин, С — 16 мин и О — 20 мин, и среднее время будет равно 14 мин. 
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Рис. 2.21 . Пример алгоритма планирования «Кратчайшая задача — первая»: запуск четырех 
задач в исходном порядке (а); запуск в соответствии с алгоритмом (б) 

Запустим задачи в соответствии с алгоритмом, как показано на рис. 2.21, б. 
Теперь значения оборотного времени составляют 4,8,12 и 20 мин соответственно, 
а среднее время равно 11 мин. Алгоритм оптимизирует задачу. Рассмотрим четы¬ 
ре процесса со временем выполнения а, Ь, с и сі. Первая задача выполняется за 
время а, вторая — за время а + Ь и т. д. Среднее оборотное время будет равно 
(4а + ЗЬ + 2с + сІ)/А. Очевидно, что вклад времени а в среднее больше, чем всех 
остальных интервалов времени, поэтому первой должна выполняться самая корот¬ 
кая задача, а последней — самая длинная, вносящая вклад, равный собственному 
оборотному времени. Точно так же рассматривается система из любого количества 
задач. 

Следует отметить, что эта схема работает лишь в случае одновременного нали¬ 
чия задач. В качестве контрпримера можно рассмотреть пять задач, А, В, С, Б н Е, 
причем первые две доступны стразу же, а три оставшиеся — еще через три минуты. 
Время выполнения этих задач составляет 2,4,1,1 и 1 мин соответственно. Вначале 
можно выбрать только А или В, поскольку остальные недоступны. Если руковод¬ 
ствоваться алгоритмом «Кратчайшая задача — Первая», задачи будут запущены 
в следующем порядке: А , В, С, Б, Е, и среднее оборотное время составит 4,6 мин. Если 
же запустить их в порядке В, С, О, Е, А, то среднее оборотное время составит 4,4 мин. 

Наименьшее оставшееся время выполнения 

Версией предыдущего алгоритма с переключениями является алгоритм наимень¬ 
шего оставшегося времени выполнения. В соответствии с этим алгоритмом плани¬ 
ровщик каждый раз выбирает процесс с наименьшим оставшимся временем вы¬ 
полнения. В этом случае также необходимо заранее знать время выполнения 
задач. Когда поступает новая задача, ее полное время выполнения сравнивается 
с оставшимся временем выполнения текущей задачи. Если время выполнения но¬ 
вой задачи меньше, текущий процесс приостанавливается и управление передает¬ 
ся новой задаче. Эта схема позволяет быстро обслуживать короткие запросы. 

Трехуровневое планирование 

Системы пакетной обработки позволяют реализовать трехуровневое планирова¬ 
ние, как показано на рис. 2.22. По мере поступления в систему новые задачи сна¬ 
чала помещаются в очередь, хранящуюся на диске. Впускной планировщик вы¬ 
бирает задание и передает его системе. Остальные задания остаются в очереди. 
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Характерный алгоритм входного контроля может заключаться в выборе смеси из 
процессов, ограниченных возможностями процессора, и процессов, ограниченных 
возможностями устройств ввода-вывода. Также возможен алгоритм, в котором 
устанавливается приоритет коротких задач перед длинными. Впускной планиров¬ 
щик волен придержать некоторые задания во входной очереди, а пропустить зада¬ 
ние, поступившее позже остальных. 


Новая 

задача 
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Очередь 

ІОІОІОЮІ 


Планировщик 

доступа 


ПроцессорО 
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о о о о о 


Оперативная 

память 


Планировщик 

памяти 


Диск 


Рис. 2.22. Трехуровневое планирование 


Как только задание попало в систему, для него будет создан соответствующий 
процесс, и он может тут же вступить в борьбу за доступ к процессору. Тем не ме¬ 
нее возможна ситуация, когда процессов слишком много и они все в памяти не 
помещаются, тогда некоторые из них будут выгружены на диск. Второй уровень 
планирования определяет, какие процессы можно хранить в памяти, а какие — 
на диске. Этим занимается планировщик памяти. 

С одной стороны, распределение процессов необходимо часто пересматривать, 
чтобы у процессов, хранящихся на диске, тоже был шанс получить доступ к про¬ 
цессору. С другой стороны, перемещение процесса с диска в память требует за¬ 
трат, поэтому к диску следует обращаться не чаще, чем раз в секунду, а может быть 
и реже. Если содержимое оперативной памяти будет слишком часто меняться, про¬ 
пускная способность диска будет расходоваться впустую, что замедлит файловый 
ввод-вывод. 

Для оптимизации эффективности системы планировщик памяти должен ре¬ 
шить, сколько и каких процессов может одновременно находиться в памяти. Ко¬ 
личество процессов, одновременно находящихся в памяти, называется степенью 
многозадачности. Если планировщик памяти обладает информацией о том, какие 
процессы ограничены возможностями процессора, а какие — возможностями 
устройств ввода-вывода, он может пытаться поддерживать смесь этих процессов в 
памяти. Можно грубо оценить, что если некая разновидность процессов будет за¬ 
нимать примерно 20 % времени процессора, то пяти процессов будет достаточно 
для поддержания постоянной занятости процессора. Более совершенная модель 
многозадачности будет рассмотрена в главе 4. 
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Планировщик памяти периодически просматривает процессы, находящиеся на 
диске, чтобы решить, какой из них переместить в память. Среди критериев, исполь¬ 
зуемых планировщиком, есть следующие: 

1. Сколько времени прошло с тех пор, как процесс был выгружен на диск или 
загружен с диска? 

2. Сколько времени процесс уже использовал процессор? 

3. Каков размер процесса (маленькие процессы не мешают)? 

4. Какова важность процесса? 

Третий уровень планирования отвечает за доступ процессов, находящихся в со¬ 
стоянии готовности, к процессору. Когда идет разговор о «планировщике», обычно 
имеется в виду именно планировщик процессора. Этим планировщиком использу¬ 
ется любой подходящий к ситуации алгоритм, как с прерыванием, так и без. Неко¬ 
торые из этих алгоритмов мы уже рассмотрели, а с другими еще ознакомимся. 

Планирование в интерактивных системах 

Теперь давайте обратимся к алгоритмам планирования, используемым в интерак¬ 
тивных системах. Все они также могут использоваться в качестве планировщика 
процессора в системах пакетной обработки. В интерактивных системах невозмож¬ 
но трехуровневое планирование, но двухуровневое (планировщик памяти и про¬ 
цессора) возможно и часто используется. Ниже мы рассмотрим алгоритмы для 
планировщика процессора. 

Циклическое планирование 

В этом подразделе мы обратимся к некоторым характерным алгоритмам планиро¬ 
вания. Одним из наиболее старых, простых, справедливых и часто используемых 
является алгоритм циклического планирования. Каждому процессу предоставля¬ 
ется некоторый интервал времени процессора, так называемый квант времени. 
Если к концу кванта времени процесс все еще работает, он прерывается, а управ¬ 
ление передается другому процессу. Разумеется, если процесс блокируется или 
прекращает работу раньше, переход управления происходит в этот момент. Реа¬ 
лизация циклического планирования проста. Планировщику нужно всего лишь 
поддерживать список процессов в состоянии готовности согласно рисунку 2.23, а. 
Когда процесс исчерпал свой лимит времени, он отправляется в конец списка 
(рис. 2.23, б). 

Текущий Следующий Текущий 



Рис. 2.23. Циклическое планирование: список процессов в состоянии готовности (а); список 
процессов в состоянии готовности после того, как процесс В исчерпал свой квант времени (б) 
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Единственным интересным моментом этого алгоритма является длина кванта. 
Переключение с одного процесса на другой занимает некоторое время — необхо¬ 
димо сохранить и загрузить регистры и карты памяти, обновить таблицы и спис¬ 
ки, сохранить и перезагрузить кэш памяти и т. п. Представим, что переключение 
процессов или переключение контекста, как его иногда называют, занимает 1 мс, 
включая переключение карт памяти, перезагрузку кэша и т. п. Пусть размер кван¬ 
та установлен в 4 мс. В таком случае 20 % процессорного времени уйдет на адми¬ 
нистрирование — это слишком много. 

Для увеличения эффективности назначим размер кванта, скажем, 100 мс. Теперь 
пропадает только 1 % времени. Но представьте, что будет в системе с разделением 
времени, если 10 пользователей одновременно нажмут клавишу возврата каретки. 
В список будет занесено 10 процессов. Если процессор был свободен, первый про¬ 
цесс будет запущен немедленно, второму придется ждать 100 мс и т. д. Последне¬ 
му процессу, возможно, придется ждать целую секунду, если все остальные не бло¬ 
кируются за время кванта. Большинству пользователей секундная задержка вряд 
ли понравится. 

Важен и тот фактор, что если установленное значение кванта больше среднего 
интервала работы процессора, переключение процессов будет происходить редко. 
Напротив, большинство процессов будут совершать блокирующую операцию 
прежде, чем истечет длительность кванта, вызывая переключение процессов. 
Устранение принудительных переключений процессов улучшает производитель¬ 
ность системы, так как переключения процессов будут происходить только тогда, 
когда это логически необходимо, то есть когда процесс заблокировался и не может 
продолжать работу. 

Вывод можно сформулировать следующим образом: слишком малый квант 
приведет к частому переключению процессов и небольшой эффективности, но 
слишком большой квант может привести к медленному реагированию на корот¬ 
кие интерактивные запросы. Значение кванта около 20-50 мс часто является ра¬ 
зумным компромиссом. 

Приоритетное планирование 

В циклическом алгоритме планирования есть важное допущение о том, что все 
процессы равнозначны. В ситуации компьютера с большим числом пользователей 
это может быть не так. Например, в университете прежде всего должны обслужи¬ 
ваться деканы, затем профессора, секретари, уборщицы и лишь потом студенты. 
Необходимость принимать во внимание подобные внешние факторы приводит к 
приоритетному планированию. Основная идея проста: каждому процессу присваи¬ 
вается приоритет, и управление передается готовому к работе процессу с самым 
высоким приоритетом. 

Даже на персональном компьютере с одним пользователем может происходить 
несколько процессов, отдельные из которых являются более важными, чем дру¬ 
гие. Демон, отвечающий за пересылку электронной почты в фоновом режиме, име¬ 
ет более низкий приоритет, чем процесс, отображающий на экране видеофильм в 
реальном времени. 

Чтобы предотвратить бесконечную работу процессов с высоким приоритетом, 
планировщик может уменьшать приоритет процесса с каждым тактом часов (то 
есть при каждом прерывании по таймеру). Если в результате приоритет текущего 
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процесса окажется ниже, чем приоритет следующего процесса, произойдет пере¬ 
ключение. Возможно предоставление каждому процессу максимального отрезка 
времени работы. Как только время кончилось, управление передается следующе¬ 
му по приоритету процессу. 

Приоритеты процессам могут присваиваться статически или динамически. 
На военной базе процессу, запущенному генералом, присваивается приоритет 100, 
полковником — 90, майором — 80, капитаном — 70, лейтенантом — 60 и т. д. А в ком¬ 
мерческом компьютерном центре выполнение заданий с высоким приоритетом 
может стоить 100 долларов в час, со средним — 75, с низким — 50. В системе 1ЖІХ 
есть команда пісе, позволяющая пользователю добровольно снизить приоритет 
своих процессов, чтобы быть вежливым по отношению к остальным пользовате¬ 
лям. Этой командой никто никогда не пользуется. 

Система может динамически назначать приоритеты для достижения своих це¬ 
лей. Например, некоторые процессы сильно ограничены возможностями устройств 
ввода-вывода и большую часть времени проводят в ожидании завершения опе¬ 
раций ввода-вывода. Когда бы ни потребовался процессор такому процессу, его 
следует немедленно предоставить, чтобы процесс мог начать следующий запрос 
ввода-вывода, который будет выполняться параллельно с вычислениями другого 
процесса. Если заставить процесс, ограниченный возможностями устройств вво¬ 
да-вывода, длительное время ждать доступа к процессору, он будет неоправданно 
долго находиться в памяти. Простой алгоритм обслуживания процессов, ограни¬ 
ченных возможностями устройств ввода-вывода, состоит в установке приоритета, 
равнбго 1//, где /— часть использованного в последний раз кванта. Процесс, ис¬ 
пользовавший всего 1 мс из 50 мс кванта, получит приоритет 50, процесс, исполь¬ 
зовавший 25 мс, получит приоритет 2, а процесс, использовавший весь квант, по¬ 
лучит приоритет 1. 

Часто бывает удобно сгруппировать процессы в классы по приоритетам и исполь¬ 
зовать приоритетное планирование среди классов, но циклическое планирование 
внутри каждого класса. На рис. 2.24 представлена система с четырьмя классами 
приоритетов. Алгоритм планирования выглядит следующим образом: пока в клас¬ 
се 4 есть готовые к запуску процессы, они запускаются один за другим согласно 
алгоритму циклического планирования, и каждому отводится квант времени. При 
этом классы с более низким приоритетом не будут их беспокоить. Если в классе 4 
нет готовых к запуску процессов, запускаются процессы класса 3 и т. д. Если при¬ 
оритеты постоянны, до процессов класса 1 процессор может не дойти никогда. 

Процессы, 
готовые к запуску 


(Самый высокий приоритет) 


(Самый низкий приоритет) 


Заголовки 

очередей 


Приоритет 4 


Приоритет 3 


Приоритет 2 


Приоритет 1 


Рис. 2.24. Приоритетный алгоритм планирования с четырьмя классами приоритетов 
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Несколько очередей 

Один из первых приоритетных планировщиков был реализован в системе СТ55 
(сошраІіЫе Нте-зЪагесі зузіет — совместимая система с разделением времени) 
[75]. Основной проблемой системы СТ55 было слишком медленное переключе¬ 
ние процессов, поскольку в памяти компьютера ІВМ 7094 мог находиться только 
один процесс. Каждое переключение означало выгрузку текущего процесса на диск 
и считывание нового процесса с диска. Разработчики СТ55 быстро сообразили, что 
эффективность будет выше, если процессам, ограниченным возможностями про¬ 
цессора, выделять больший квант времени, чем если предоставлять им небольшие 
кванты, но часто. С одной стороны, это уменьшит количество перекачек из памяти 
на диск, а с другой — приведет к ухудшению времени отклика, как мы уже видели. 
В результате было разработано решение с классами приоритетов. Процессам клас¬ 
са с высшим приоритетом выделялся один квант, процессам следующего класса — 
два кванта, следующего — четыре кванта и т. д. Когда процесс использовал все от¬ 
веденное ему время, он перемещался на класс ниже. 

В качестве примера рассмотрим процесс, которому необходимо производить 
вычисления в течение 100 квантов. Вначале ему будет предоставлен один квант, 
затем он будет перекачан на диск. В следующий раз ему достанется 2 кванта, за¬ 
тем 4, 8,16, 32, 64, хотя из 64 он использует только 37. В этом случае понадобится 
всего 7 перекачек (включая первоначальную загрузку) вместо 100, которые пона¬ 
добились бы при использовании циклического алгоритма. Помимо этого, по мере 
погружения в очереди приоритетов процесс будет все реже запускаться, предо¬ 
ставляя процессор более коротким процессам. 

Чтобы процессу, который при запуске считался долгим, но позже стал интерак¬ 
тивным, не погибнуть в недрах планирования, была разработана следующая страте¬ 
гия. Как только с терминала приходит сигнал возврата каретки, процесс, соответ¬ 
ствующий этому терминалу, переносится в класс высшего приоритета, поскольку 
предполагается, что он становится интерактивным. Однажды пользователь, запу¬ 
стивший процесс, сильно ограниченный возможностями процессора, обнаружил, 
что бездумное нажимание клавиши возврата каретки существенно уменьшает вре¬ 
мя отклика, и рассказал об этом друзьям. Мораль этой истории такова: осуще¬ 
ствить задуманное на практике гораздо сложней, чем в теории. 

Для разделения процессов по классам используются также многие другие алго¬ 
ритмы. Например, в системе ХОЗ 940, разработанной в Беркли [192], было четыре 
класса приоритетов, называвшихся: терминал, ввод-вывод, короткий квант и длин¬ 
ный квант. Когда запускался процесс, ожидающий вывода на терминал, он пере¬ 
мещался в класс высшего приоритета (терминал). Когда снималась блокировка 
процесса, ожидавшего доступа к диску, он перемещался во второй класс. Если к кон¬ 
цу отведенного времени процесс все еще работал, он сначала перемещался в третий 
класс. Если процесс слишком много раз полностью использовал свой квант време¬ 
ни, не блокируясь на терминале или другом устройстве ввода-вывода, он переме¬ 
щался в последний класс. Этот метод используется во многих системах для пре¬ 
доставления преимущества интерактивным процессам по сравнению с фоновыми. 

«Самый короткий процесс — следующий» 

Поскольку алгоритм « Кратчайшая задача — первая» минимизирует среднее оборот¬ 
ное время в системах пакетной обработки, хотелось бы использовать его и в инте- 
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рактивных системах. В известной степени это возможно. Интерактивные процес¬ 
сы чаще всего следуют схеме «ожидание команды, исполнение команды, ожида¬ 
ние команды, исполнение команды...» Если рассматривать выполнение каждой 
команды как отдельную задачу, можно минимизировать общее среднее время от¬ 
клика, запуская первой самую короткую задачу. Единственная проблема состоит 
в том, чтобы понять, какой из ожидающих процессов самый короткий. 

Один из методов основывается на оценке длины процесса, базирующейся на 
предыдущем поведении процесса. При этом запускается процесс, у которого оце¬ 
ненное время самое маленькое. Допустим, что предполагаемое время исполнения 
команды равно Т 0 и предполагаемое время следующего запуска равно Г,. Можно 
улучшить оценку времени, взяв взвешенную сумму этих времен аТ 0 + (1 - а)Т^. 
Выбирая соответствующее значение а, мы можем заставить алгоритм оценки быс¬ 
тро забывать о предыдущих запусках или, наоборот, помнить о них в течение дол¬ 
гого времени. Взяв а = 1/2, мы получим серию оценок: 

То, Г 0 /2 + Г,/2, Г 0 /4 + Г,/4 + Т 2 / 2, Г 0 /8 + Г,/8 + Г 2 /4 + Г 3 /2. 

После трех запусков вес Г 0 в оценке уменьшится до 1/8. 

Метод оценки следующего значения серии через взвешенное среднее предыду¬ 
щего значения и предыдущей оценки часто называют старением. Этот метод при¬ 
меним во многих ситуациях, где необходима оценка по предыдущим значениям. 
Проще всего реализовать старение при а = 1/2. На каждом шаге нужно всего лишь 
добавить к текущей оценке новое значение и разделить сумму пополам (сдвинув 
вправо на 1 бит). 

Гарантированное планирование 

Принципиально другим подходом к планированию является предоставление 
пользователям реальных обещаний и затем их выполнение. Вот одно обещание, 
которое легко произнести и легко выполнить: если вместе с вами процессором 
пользуются п пользователей, вам будет предоставлено 1 /п мощности процессора. 
И в системе с одним пользователем и п запущенными процессорами каждому дос¬ 
танется 1 /п циклов процессора. 

Чтобы выполнить это обещание, система должна отслеживать распределение 
процессора между процессами с момента создания каждого процесса. Затем сис¬ 
тема рассчитывает количество ресурсов процессора, на которое процесс имеет пра¬ 
во, например время с момента создания, деленное на п. Теперь можно сосчитать 
отношение времени, предоставленного процессу, к времени, на которое он имеет 
право. Полученное значение 0,5 означает, что процессу выделили только полови¬ 
ну положенного, а 2,0 означает, что процессу досталось в два раза больше, чем по¬ 
ложено. Затем запускается процесс, у которого это отношение наименьшее, пока 
оно не станет больше, чем у его ближайшего соседа. 

Лотерейное планирование 

Хотя идея обещаний пользователям и их выполнения хороша, но ее трудно реали¬ 
зовать. Для более простой реализации предсказуемых результатов используется 
другой алгоритм, называемый лотерейным планированием [352]. 
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В основе алгоритма лежит раздача процессам лотерейных билетов на доступ к 
различным ресурсам, в том числе и к процессору. Когда планировщику необходимо 
принять решение, выбирается случайным образом лотерейный билет, и его облада¬ 
тель получает доступ к ресурсу. Что касается доступа к процессору, «лотерея» может 
происходить 50 раз в секунду, и победитель получает 20 мс времени процессора. 

Если перефразировать Джорджа Оруэлла: «Все процессы равны, но некоторые 
равнее других». Более важным процессам можно раздать дополнительные биле¬ 
ты, чтобы увеличить вероятность выигрыша. Если всего 100 билетов и 20 из них 
находятся у одного процесса, то ему достанется 20 % времени процессора. В отличие 
от приоритетного планировщика, в котором очень трудно оценить, что означает, ска¬ 
жем, приоритет 40, в лотерейном планировании все очевидно. Каждый процесс 
получит процент ресурсов, примерно равный проценту имеющихся у него билетов. 

Лотерейное планирование характеризуется несколькими интересными свой¬ 
ствами. Например, если при создании процессу достается несколько билетов, то 
уже в следующей лотерее его шансы на выигрыш пропорциональны количеству 
билетов. Другими словами, лотерейное планирование обладает высокой отзывчи¬ 
востью. 

Взаимодействующие процессы могут при необходимости обмениваться биле¬ 
тами. Так, если клиентский процесс посылает сообщение серверному процессу 
и затем блокируется, он может передать все свои билеты серверному процессу, что¬ 
бы увеличить шанс запуска сервера. Когда серверный процесс заканчивает рабо¬ 
ту, он может вернуть все билеты обратно. Действительно, если клиентов нет, то 
серверу билеты вовсе не нужны. 

Лотерейное планирование позволяет решать задачи, которые не решить с по¬ 
мощью других алгоритмов. В качестве примера можно привести видеосервер, на 
котором несколько процессов передают своим клиентам потоки видеоинформации 
с различной частотой кадров. Предположим, что процессы используют частоты 10, 
20 и 25 кадров в секунду. Предоставив процессам соответственно 10, 20 и 25 биле¬ 
тов, можно реализовать загрузку процессора в желаемой пропорции 10:20:25. 

Справедливое планирование 

До сих пор мы предполагали, что каждый процесс управляется независимо от 
того, кто его хозяин. Поэтому если пользователь 1 создаст 9 процессов, а пользо¬ 
ватель 2 — 1 процесс, то с использованием циклического планирования или в слу¬ 
чае равных приоритетов пользователю 1 достанется 90 % процессора, а пользова¬ 
телю 2 всего 10. 

Чтобы избежать подобных ситуаций, некоторые системы обращают внимание 
на хозяина процесса перед планированием. В такой модели каждому пользователю 
достается некоторая доля процессора, и планировщик выбирает процесс в соот¬ 
ветствии с этим фактом. Если в нашем примере каждому из пользователей было 
обещано по 50 % процессора, то им достанется по 50 % процессора, независимо от 
количества процессов. 

В качестве примера рассмотрим систему и двух пользователей, каждому из ко¬ 
торых отведено по 50 % процессора. У первого пользователя четыре процесса; А, В, 
С и Д у второго один процесс Е. Если используется циклическое планирование, 
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цепочка процессов, удовлетворяющая всем требованиям, будет выглядеть следу¬ 
ющим образом: 

АЕВЕСЕБЕ АЕВЕСЕБЕ... 

С другой стороны, если первому пользователю положено вдвое больше ресур¬ 
сов, чем второму, мы получим 

АВЕСБЕ АВЕСОЕ... 

Существует множество других решений, используемых в зависимости от' кон¬ 
кретных представлений о справедливости. 

Планирование в системах реального времени 

В системах реального времени существенную роль играет время. Чаще всего одно 
или несколько внешних физических устройств генерируют входные сигналы, 
и компьютер должен адекватно на них реагировать в течение заданного промежут¬ 
ка времени. Например, компьютер в проигрывателе компакт-дисков получает биты 
от дисковода и должен за очень маленький промежуток времени конвертировать 
их в музыку. Если процесс конвертации будет слишком долгим, звук окажется 
искаженным. Подобные системы также используются для наблюдения за пациен¬ 
тами в палатах интенсивной терапии, в качестве автопилота самолета, для управ¬ 
ления роботами на автоматизированном производстве. В любом из этих случаев 
запоздалая реакция ничуть не лучше, чем отсутствие реакции. 

Системы реального времени делятся на жесткие системы реального времени, 
что означает наличие жестких сроков для каждой задачи (в них обязательно надо 
укладываться), и гибкие системы реального времени, в которых нарушения вре¬ 
менного графика нежелательны, но допустимы. В обоих случаях реализуется раз¬ 
деление программы на несколько процессов, каждый из которых предсказуем. Эти 
процессы чаще всего бывают короткими и завершают свою работу в течение секун¬ 
ды. Когда появляется внешний сигнал, именно планировщик должен обеспечить 
соблюдение графика. 

Внешние события, на которые система должна реагировать, можно разделить 
на периодические (возникающие через регулярные интервалы времени) и непери¬ 
одические (возникающие непредсказуемо). Возможно наличие нескольких пери¬ 
одических потоков событий, которые система должна обрабатывать. В зависимос¬ 
ти от времени, затрачиваемого на обработку каждого из событий, может оказаться, 
что система не в состоянии своевременно обработать все события. Если в систему 
поступает т периодических событий, событие с номером і поступает с периодом Р„ 
и на его обработку уходит С, секунд работы процессора, все потоки могут быть сво¬ 
евременно обработаны только при выполнении условия 

С<,. 
р, 

Системы реального времени, удовлетворяющие этому условию, называются 

поддающимися планированию или планируемыми. 
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В качестве примера рассмотрим гибкую систему реального времени с тремя 
периодическими сигналами с периодами в 100, 200 и 500 мс соответственно. Если 
на обработку этих сигналов уходит 50,30 и 100 мс соответственно, система является 
поддающейся планированию, поскольку 0,5 + 0,15 + 0,2 < 1. Даже при добавлении 
четвертого сигнала с периодом в 1 с системой все равно можно будет управлять 
при помощи планирования, пока время обработки сигнала не будет превышать 
150 мс. В этих расчетах существенным является предположение, что время пере¬ 
ключения между процессами пренебрежимо мало. 

Алгоритмы планирования для систем реального времени могут быть как ста¬ 
тическими, так и динамическими. В первом случае все решения планирования 
принимаются заранее, еще до запуска системы. Во втором случае решения пла¬ 
нирования принимаются по ходу дела. Статическое планирование применимо толь¬ 
ко при наличии достоверной информации о работе, которую необходимо выпол¬ 
нить,' и о временном графике, которого нужно придерживаться. Динамическое 
планирование не нуждается в подобных ограничениях. На этом мы отложим изу¬ 
чение алгоритмов планирования и вернемся к ним в главе 7, посвященной муль¬ 
тимедийным системам реального времени. 

Политика и механизм 

Вплоть до этого момента мы подразумевали, что процессы в системе принадле¬ 
жат различным пользователям и конкурируют за доступ к процессору. Чаще все¬ 
го именно так все и выглядит, но возможна ситуация, в которой у одного процесса 
есть много дочерних процессов, работающих под его управлением. Например, 
у процесса, управляющего базой данных, может быть много дочерних процессов, 
обрабатывающих отдельные запросы или выполняющих конкретные функции 
(анализ запроса, доступ к диску и т. п.). Вполне возможно, что родительский про¬ 
цесс лучше представляет, какой из его дочерних процессов более важен (или для 
которого фактор времени более критичен), а какой — менее важен. К сожалению, 
ни один из рассмотренных нами планировщиков не может получать информацию 
от пользовательских процессов и учитывать ее при принятии решений планиро¬ 
вания. В результате планировщики редко принимают оптимальное решение. 

Решить проблему можно, разделив механизм планирования и политику пла¬ 
нирования. Таким образом, мы реализуем ситуацию, в которой алгоритм плани¬ 
рования будет каким-либо образом параметризован, но параметры могут быть за¬ 
даны процессом пользователя. Обратимся еще раз к примеру базы данных. Пусть 
ядро использует алгоритм приоритетного планирования, но существует системный 
запрос, посредством которого процесс может устанавливать (и менять) приоритеты 
своих дочерних процессов. В этом случае родительский процесс может управлять 
планированием дочерними процессами, хотя сам он планирования не осуществ¬ 
ляет. Механизм определяется ядром, но политику задает процесс пользователя. 

Планирование потоков 

В случае нескольких процессов, каждый из которых разделен на несколько пото¬ 
ков, реализуются два уровня параллелизма: на уровне потоков и на уровне про- 
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цессов. Планирование в таких системах существенно зависит от того, поддержи¬ 
ваются ли потоки на уровне пользователя, на уровне ядра или и те и другие. 

Для начала рассмотрим потоки на уровне пользователя. Поскольку ядро не зна¬ 
ет о существовании потоков, оно выполняет обычное планирование, выбирая 
процесс А и предоставляя ему квант времени. Планировщик потоков внутри 
процесса А выбирает поток, например А\. Поскольку в случае потоков прерыва¬ 
ния по таймеру нет, выбранный поток будет работать столько, сколько пожелает. 
Если он займет весь квант процесса А, ядро передаст управление другому процессу. 

Когда управление снова перейдет к процессу А, поток А1 возобновит работу. Он 
будет продолжать потреблять все процессорное время, предоставляемое процессу А, 
пока не закончит свою работу. Впрочем, асоциальное поведение потока А\ на дру¬ 
гие процессы не повлияет. Они будут продолжать получать долю процессорного 
времени, которую планировщик считает справедливой, независимо от того, что 
происходит внутри процесса А. 

Теперь представим, что потокам процесса Л нужно всего лишь 5 мс из отведен¬ 
ного кванта в 50 мс. Соответственно, каждый из них будет выполнять свою неболь¬ 
шую работу и возвращать процессор планировщику потоков. Это приведет к сле¬ 
дующей цепочке: А1,А2,АЗ,А1,А2, АЗ, А 1, А 2, АЗ, А 1, прежде чем управление будет 
передано процессу В. Эта ситуация представлена на рис. 2.25, а. 

Процесс А Процесс Б Процесс А Процесс Б 



Возможно: А1, А2, АЗ, А1, А2, АЗ Возможно: А1, А2, АЗ, А1, А2, АЗ 

Невозможно: А1, В1, А2, В2, АЗ, ВЗ Также возможно: А1, В1, А2, В2, АЗ, ВЗ 


а б 

Рис. 2.25. Возможное планирование потоков: на уровне пользователя в случае кванта в 50 мс 
и потоков, блокирующихся через 5 мс (а); на уровне ядра с теми же характеристиками (б) 

В качестве алгоритма планирования для системы поддержки исполнения про¬ 
грамм можно взять любой из уже рассмотренных нами. Наиболее часто исполь¬ 
зуются алгоритмы циклического и приоритетного планирования. Единственной 
проблемой является отсутствие таймера, который прерывал бы затянувшуюся 
работу потока. 

Теперь рассмотрим потоки на уровне ядра. В этой ситуации ядро выбирает сле¬ 
дующий поток. При этом ядро не обязано принимать во внимание, какой поток 
принадлежит какому процессу, хотя у него есть такая возможность. Потоку пре¬ 
доставляется квант времени и по истечении этого кванта управление передается 
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другому потоку. В случае кванта в 50 мс и потоков, блокирующихся через 5 мс, 
цепочка длиной в 30 мс может выглядеть так: Л1, 61, А2, В2, АЗ, В 3, что было не¬ 
возможно в случае потоков на уровне пользователя. Эта ситуация представлена 
на рис. 2.25, б. 

Основное различие между реализацией потоков на уровне пользователя и реа¬ 
лизацией их на уровне ядра состоит в производительности. Для переключения 
потоков на уровне пользователя требуется выполнение всего нескольких машин¬ 
ных команд. Для переключения потоков на уровне ядра нужно выполнить полное 
переключение контекста с заменой карты памяти и аннулированием кэша, что 
выполняется на несколько порядков медленнее. С другой стороны, при реализа¬ 
ции потоков на уровне пользователя блокировка потока на устройстве ввода-вы¬ 
вода блокирует весь процесс, чего не случается с потоками на уровне ядра. 

Поскольку ядро знает, что на переключение от потока процесса Л к потоку 
процесса В будет затрачено больше ресурсов, чем на передачу управления следу¬ 
ющему потоку процесса Л (из-за карты памяти и кэша), эта информация может 
учитываться при принятии решения планирования. Например, при наличии двух 
одинаково важных потоков, один из которых принадлежит тому же процессу, что 
и только что блокированный поток, а второй — другому процессу, предпочтение 
будет отдано первому потоку. 

Еще одним важным фактором является возможность совместного использо¬ 
вания потоков на уровне пользователя и специализированного планировщика по¬ 
токов. Рассмотрим, например, \ѵеЬ-сервер на рис. 2.7. Пусть один рабочий поток 
только что заблокирован, а диспетчер и два оставшихся рабочих потока находятся 
в состоянии готовности. Который из них будет запущен? Система поддержки ис¬ 
полнения программ, которая обладает информацией о задаче каждого потока, вы¬ 
берет следующим диспетчера, чтобы он запустил следующий рабочий поток. По¬ 
добная стратегия увеличивает степень параллелизма в среде, где рабочие потоки 
часто блокируются на обращениях к диску. В случае потоков на уровне ядра оно 
не знает, чем занимается каждый поток (хотя у них могут быть разные приорите¬ 
ты). В целом специализированные планировщики потоков лучше управляют при¬ 
ложениями, чем ядро. 


Изучение процессов и потоков 

В главе 1 мы рассмотрели некоторые текущие исследования структуры операци¬ 
онных систем. В этой и следующих главах мы рассмотрим более конкретные ис¬ 
следования и начнем с процессов. Как вы поймете позже, что-то уже устоялось, 
что-то еще нет. Большая часть исследований направлена на новые темы. 

Концепция процесса является хорошим примером уже разработанной темы. 
Практически в каждой системе есть представление о процессе как о контейнере 
для группировки связанных ресурсов, таких как адресное пространство, потоки, 
открытые файлы, доступ к защищенным ресурсам и т. п. Способ группировки слег¬ 
ка различается в разных системах, но эти различия видны лишь на уровне проек¬ 
тирования. С основной идеей уже почти никто не спорит, и новых исследований 
по этой теме немного. 
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Іфдея потоков более свежая, поэтому по этой теме до сих пор ведется несколько 
исследований. Хаузер (Наизег) [149] рассматривал, как реальные программы ис¬ 
пользуют потоки, и выработал 10 различных парадигм использования потоков. 
Планирование потоков (с одним и несколькими процессорами) до сих пор изуча¬ 
ется, и эта тема близка многим исследователям [36, 47, 59, 73, 101, 120, 264]. Тем 
не менее не так уж много разработчиков операционных систем ломают головы день 
и ночь, ощущая катастрофический недостаток алгоритмов планирования. Похо¬ 
же, что это поле исследований пока не ощущает инфляции спроса. 

Тесно связаны с потоками темы синхронизации потоков и взаимного исключения. 
В 70-х и 80-х годах этими исследованиями занимались все, поэтому в настоящее 
время работ по этим темам немного. Проводимые исследования в основном направ¬ 
лены на повышение эффективности (например, [207]), разработку методов детек¬ 
тирования ошибок синхронизации [293] и переработку старых концепций [319]. 
Наконец, до сих пор производятся Р05ІХ-совместимые пакеты потоков [9, 235]. 


Резюме 

При рассмотрении операционных систем с точки зрения концептуальной модели, 
состоящей из последовательных процессов, работающих параллельно, эффект пре¬ 
рываний скрыт. Процессы можно динамично создавать и завершать. У каждого 
процесса есть собственное адресное пространство. 

Для некоторых приложений удобно иметь несколько потоков управления в од¬ 
ном процессе. Эти потоки планируются независимо друг от друга и у каждого есть 
собственный стек, но все потоки одного процесса совместно используют общее 
адресное пространство. Потоки можно реализовать в пространстве пользователя 
или в пространстве ядра. 

Процессы могут взаимодействовать между собой с помощью примитивов меж¬ 
процессного взаимодействия, таких как семафоры, мониторы или сообщения. Эти 
примитивы используются для исключения ситуации, в которой два процесса одно¬ 
временно находятся в своих критических областях, что приводило бы к хаосу. Про¬ 
цесс может находиться в состоянии действия, готовности или блокировки и может 
менять состояние в случае выполнения им (или другим процессом) примитива 
межпроцессного взаимодействия. Примерно так же выполняется взаимодействие 
потоков. 

Примитивы межпроцессного взаимодействия используются для решения таких 
проблем, как проблема производителя и потребителя, проблема обедающих фило¬ 
софов, проблема читателей и писателей и проблема спящего брадобрея. Но даже 
при использовании примитивов необходимо отслеживать ситуации, приводящие 
к ошибкам и взаимоблокировкам. 

Известны многие алгоритмы планирования. Некоторые из них, такие как «Крат¬ 
чайшая задача — первая», используются в основном в системах пакетной обработ¬ 
ки данных. Другие используются в интерактивных системах (циклическое плани¬ 
рование, приоритетное планирование, многоуровневые очереди, гарантированное 
планирование, лотерейное планирование и разделенное планирование). В неко¬ 
торых системах различаются механизм планирования и политика планирования, 
что позволяет пользователю управлять алгоритмом планирования. 
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Вопросы 

1. На рис. 2.2 представлены три состояния процессов. Теоретически между 
этими тремя состояниями могут быть шесть переходов, но на рисунке пока¬ 
зано только четыре. Возможна ли ситуация, в которой произойдет один или 
оба пропущенных перехода? 

2. Представьте, что вы разрабатываете архитектуру компьютера высокого уров¬ 
ня, который переключает процессы аппаратно, а не с помощью прерываний. 
Какая информация потребуется процессору? Опишите возможную реали¬ 
зацию переключения процессов с использованием аппаратного обеспечения. 

3. На всех существующих компьютерах как минимум часть обработчиков пре¬ 
рываний написана на ассемблере. Почему? 

4. Когда прерывание или системный запрос передает управление операцион¬ 
ной системе, обычно используется область стека ядра, а не стек прерванно¬ 
го процесса. Почему? 

5. В тексте утверждалось, что модель, представленная на рис. 2.4, а, не подхо¬ 
дит для файлового сервера с кэшем в памяти. Почему? Может ли каждый 
процесс иметь собственный кэш? 

6. В табл. 2.3 набор регистров относится к элементам потока, а не процесса. 
Почему? В конце концов, в компьютере всего один набор регистров. 

7. В случае разветвления многопоточного процесса возникнет проблема, если 
дочернему процессу достанутся копии всех потоков. Пусть один из исход¬ 
ных потоков ожидал ввода с клавиатуры. После ветвления два потока будут 
ожидать ввода с клавиатуры, по одному в каждом процессе. Может ли такая 
проблема возникнуть в случае ветвления однопоточного процесса? 

8. На рис. 2.7 представлен многопоточный мюЬ-сервер. Если единственным 
способом прочитать информацию из файла является обычный блокирующий 
системный запрос геаф что, по вашему мнению, используется для сервера — 
потоки на уровне пользователя или на уровне ядра? Почему? 

9. Почему поток должен добровольно отказываться от доступа к процессору, 
вызывая ікгеасІ_уеІ(1 ? В конце концов, поток может никогда не получить 
процессор обратно, поскольку прерывания по таймеру нет. 

10. Может ли поток быть прерван прерыванием по таймеру? Если да, то при 
каких обстоятельствах? Если нет, то почему? 

11. В этой задаче вам нужно сравнить считывание файла через однопоточный и 
многопоточный файловые серверы. Получение запроса, его диспетчеризация 
и обработка занимают 15 мс при условии наличия требуемых данных в блоч¬ 
ном кэше. В каждом третьем случае требуется обращение к диску, занимающее 
75 мс, в течение которых поток находится в состоянии ожидания. Сколько 
запросов в секунду обработает однопоточный сервер? А многопоточный? 

12. В тексте был описан многопоточный \ѵеЬ-сервер и показано, почему он луч¬ 
ше, чем однопоточный сервер или конечный автомат. Возможна ли ситуа¬ 
ция, в которой однопоточный сервер будет лучше? Приведите пример. 
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13. В разделе, посвященном глобальным переменным в потоках, процедура 
сгеаіе_&ІоЪаІ использовалась для выделения участка памяти для хранения 
указателя на переменную, но не самой переменной. Является это условие 
необходимым, или процедуры будут точно так же работать, если в этом уча¬ 
стке памяти будут храниться сами переменные? 

14. Рассмотрим систему, в которой все потоки реализованы в пространстве 
пользователя и система поддержки исполнения программ получает преры¬ 
вание по таймеру раз в секунду. Пусть прерывание получено в тот момент, 
когда поток контролируется системой управления программ. К какой про¬ 
блеме это может привести? Предложите способ решения этой проблемы. 

15. Рассмотрим операционную систему, в которой нет никакого механизма, по¬ 
хожего на системный запрос $е1есЬ, чтобы узнать заранее, приведет ли к 
блокировке считывание информации из файла, канала или устройства. 
Зато в этой системе есть аварийный таймер, прерывающий блокированные 
системные запросы. Возможна ли в такой системе реализация потоков в про¬ 
странстве пользователя? Поясните. 

16. Может ли в случае потоков в пространстве пользователя возникнуть про¬ 
блема инверсии приоритета, рассмотренная в разделе «Примитивы межпро¬ 
цессного взаимодействия»? Почему? 

17. В системе с потоками на уровне пользователя каждому Потоку соответству¬ 
ет собственный стек или каждому процессу? А в системе с потоками на 
уровне ядра? Поясните. 

18. Что такое состояние состязания? 

19. При разработке компьютера он сначала моделируется программой, выпол¬ 
няющей одновременно только одну команду. Даже компьютер с нескольки¬ 
ми процессорами моделируется также последовательно. Может ли в такой 
ситуации возникнуть состояние соревнования, когда одновременных собы¬ 
тий нет? 

20. Будет ли работать решение активного ожидания с использованием перемен¬ 
ной іит (см. рис. 2.16) в случае двух процессоров, совместно использующих 
общую память? 

21. Будет ли решение Петерсона проблемы взаимного исключения (листинг 2.1) 
работать в случае планирования процессов с переключениями? В случае 
планирования без переключений? 

22. Рассмотрим компьютер, в котором нет инструкции Т5Ц но есть инструкция 
для обмена содержимого регистра и слова памяти за одну неделимую опе¬ 
рацию. Можно ли использовать эту инструкцию для написания программы 
епіег_ге§іоп, аналогичной листингу 2.3? 

23. Опишите коротко, как реализовать семафоры в операционной системе, уме¬ 
ющей блокировать прерывания. 

24. Покажите, как можно реализовать считающие семафоры (то есть семафо¬ 
ры, способные хранить произвольные значения) при помощи только бинар¬ 
ных семафоров и обычных машинных команд. 
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25. Если в системе всего два процесса, имеет ли смысл использовать для их син¬ 
хронизации барьер? Почему? 

26. В разделе «Примитивы межпроцессного взаимодействия» была описана ситу¬ 
ация с высокоприоритетным процессом Н и низкоприоритетным процессом I, 
которая приводила к вечному зацикливанию процесса Н. Может ли возник¬ 
нуть подобная проблема, если вместо приоритетного планирования исполь¬ 
зовать циклическое? Поясните. 

27. Можно ли синхронизировать два потока одного процесса, используя сема¬ 
фор в ядре, если потоки реализованы в пространстве ядра? Если потоки реа¬ 
лизованы в пространстве пользователя? Предполагается, что потоки осталь¬ 
ных процессов не имеют доступа к семафору. Поясните ответы. 

28. Синхронизация в мониторах происходит с использованием переменных 
состояния и двух специальных операций, маИ и зідпаі. Более общая форма 
синхронизации предполагает один примитив ѵ/аіЕипЕі 1 с произвольным 
булевым предикатом в качестве параметра. Например, 

маШпІЗІ х<0 ог у+г<п 

В этом случае примитив $ідпа! больше не нужен. Эта схема существенно 
более общая, чем схема Хоара и Бринча Хансена, но тем не менее она не 
используется. Почему? Подсказка', подумайте о реализации. 

29. В ресторане быстрого обслуживания есть четыре категории обслуживаю¬ 
щего персонала: 1) работники, принимающие заказы; 2) повара, готовящие 
пищу; 3) специалисты по упаковке блюд и 4) кассиры, принимающие у кли¬ 
ентов деньги и выдающие еду. Каждому из видов персонала можно сопоста¬ 
вить последовательный процесс взаимодействия. Какой формой межпроцесс¬ 
ного взаимодействия они пользуются? Свяжите эту модель с процессами 
в ШІХ. 

30. Рассмотрим систему передачи сообщений, использующую почтовые ящики. 
При попытке послать сообщение в полный ящик или получить сообщение 
из пустого ящика процесс не блокируется, а получает код ошибки. Затем 
процесс повторяет попытку, пока она не окажется успешной. Приведет ли 
подобная схема к условию состязания? 

31. Почему в процедуре Іаке _$огкз решения задачи обедающих философов (ли¬ 
стинг 2.11) переменной состояния присваивается значение НІ/ЫСЯУ? 

32. Рассмотрим процедуру риі _}огкз в листинге 2.11. Пусть переменной состо¬ 
яния присваивается значение ТНШКШС после двух вызовов процедуры Іезі, 
а не до. Как это повлияет на решение? 

33. Проблему читателей и писателей можно формулировать по-разному, в за¬ 
висимости от того, какие процессы и в какое время могут быть запущены. 
Тщательно опишите три варианта задачи, в каждом из которых предоставля¬ 
ется (или не предоставляется) преимущество одной из категорий. В каждом 
варианте укажите, что происходит, когда читающий или пишущий процесс 
готов обратиться к базе данных, и что происходит, когда процесс заканчива¬ 
ет работу с базой. 
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34. Компьютеры СБС 6600 могут обрабатывать до 10 процессов ввода-вывода 
одновременно, используя интересную форму циклического планирования, 
называемую разделением процессора. Переключение между процессами 
происходит после каждой команды, поэтому команда 1 поступает от перво¬ 
го процесса, команда 2 — от второго и т. д. Переключение процессов произ¬ 
водится. аппаратными средствами, и издержки равны нулю. Если в отсут¬ 
ствие других процессов процессу для выполнения работы нужно Т секунд, 
сколько ему потребуется времени в случае п процессов? 

35. Обычно планировщики с циклическим алгоритмом поддерживают список 
процессов, готовых к работе, причем каждый процесс находится в списке 
в единственном экземпляре. Что произойдет, если процесс окажется в спис¬ 
ке дважды? Существует ли причина, по которой подобное изменение будет 
полезным? 

36. Можно ли определить путем анализа исходного кода принадлежность про¬ 
цесса к процессам, ограниченным возможностями процессора или устройств 
ввода-вывода? Как это можно определить во время выполнения программы? 

37. В разделе «Когда планировать?» упоминалось, что планирование может 
быть усовершенствовано, если важный процесс может сыграть свою роль 
в выборе процесса, следующего за ним. Опишите ситуацию, в которой это 
можно использовать, и объясните, как. 

38. Измерения показали, что время выполнения среднестатистического процес¬ 
са до блокировки ввода-вывода равно Т. На переключение между процесса¬ 
ми уходит время 5, которое теряется впустую. Напишите формулу расчета 
эффективности для циклического планирования с квантом Д принимаю¬ 
щим следующие значения: 

а) <2 = °°, 

б) д>г, 

в) 5<0.<Т, 

г) 

д) (2 около 0. 

39. Запуска ожидают пять задач. Предполагаемое время выполнения задач со¬ 
ставляет 9,6,3,5 и X. В каком порядке их следует запустить, чтобы миними¬ 
зировать среднее время отклика? (Ответ должен зависеть от X.) 

40. Пять пакетных задач, А, В, С, Д Е поступают в компьютерный центр прак¬ 
тически одновременно. Ожидается, что время их выполнения составит 10, 
6, 2, 4 и 8 мин. Их установленные приоритеты составляют 3, 5, 2, 1 и 4, при¬ 
чем 5 — высший приоритет. Определите среднее оборотное время для каж¬ 
дого из следующих алгоритмов планирования, пренебрегая временем, теря¬ 
ющимся при переключении между процессами: 

а) циклическое планирование; 

б) приоритетное планирование; 

в) «первым пришел — первым обслужен» (в порядке 10, 6, 2, 4, 8); 

г) «кратчайшая задача — первая». 
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В случае а предполагается, что система многозадачная и каждой задаче до¬ 
стается справедливая доля процессорного времени. В случаях б— г предпо¬ 
лагается, что в каждый момент времени запущена одна задача, работающая 
вплоть до завершения. Все задачи ограничены исключительно возможнос¬ 
тями процессора. 

41. Процессу, запущенному в системе СТ55, для завершения необходимо 30 кван¬ 
тов. Сколько раз он будет перекачан на диск, считая самый первый раз (преж¬ 
де, чем он был запущен)? 

42. Предложите защиту от обмана системы приоритетов СТ55 случайными на¬ 
жатиями клавиши возврата каретки. 

43. Для предсказания времени выполнения используется алгоритм старения 
са = 1/2. Предыдущие четыре значения времени составляли 40,20,40 и 15 мс 
(первое значение — самое давнее). Оцените следующее время выполнения. 

44. В гибкую систему реального времени поступает четыре периодических сиг¬ 
нала с периодами 50, 100, 200 и 250 мс. На обработку каждого сигнала тре¬ 
буется 35, 20, 10 и х мс времени процессора. Укажите максимальное значе¬ 
ние х, при котором система остается поддающейся планированию. 

45. Объясните причины широкого использования двухуровневого планиро¬ 
вания. 

46. Рассмотрите систему, в которой желательно разделить механизм и страте¬ 
гию планирования потоков на уровне ядра. Предложите средства достиже¬ 
ния этой цели. 

47. Напишите сценарий оболочки, которая создает файл, содержащий последо¬ 
вательные числа, путем считывания последнего числа, прибавления к нему 
единицы и записывания результата в конец файла. Запустите одну копию 
сценария в качестве фонового процесса и одну — в качестве приоритетного 
процесса. Сколько времени пройдет, прежде чем возникнет состояние со¬ 
ревнования? Что в данной модели является критической областью? Изме¬ 
ните сценарий, чтобы избежать состояния состязания. ( Подсказка : восполь¬ 
зуйтесь следующим выражением, чтобы заблокировать файл данных.) 

Іп Гііе Гііе.іоск 

48. Предположим, что у вас есть операционная система с семафорами. Реали¬ 
зуйте систему сообщений. Напишите процедуры для отсылки и получения 
писем. 

49. Решите задачу обедающих философов, используя мониторы вместо сема¬ 
форов. 

50. Некий университет решил продемонстрировать свою политкорректность, 
применив известную доктрину верховного суда США «Равенство порознь 
равенством не является» не только к цвету кожи, но и к полу. Результатом 
этого решения явились совместные ванные комнаты в общежитиях. Тем не 
менее в поддержку исторически сложившейся традиции университет по¬ 
становляет, что если в ванной комнате есть женщина, то другая женщина 
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может туда зайти, а мужчина не может, и наоборот. На двери ванной есть 
индикатор, показывающий, в каком из трех состояний находится ванная: 

а) никого нет; 

б) в ванной женщины; 

в) в ванной мужчины. 

Напишите на своем любимом языке программирования следующие проце¬ 
дуры: тотап_а)аШ8_ро_еп1ег , тап_ 10 апСх_(,о_епСег, Х0отап_1еаѵез, тап_1еаѵех. 
Вы можете использовать любые счетчики и методы синхронизации. 

51. Перепишите программу из листинга 2.12, чтобы она обрабатывала большее 
количество процессов. 

52. Напишите алгоритм для решения задачи производителя и потребителя с 
использованием потоков и разделенного буфера. Однако не используйте 
семафоры и другие примитивы синхронизации для защиты совместно ис¬ 
пользуемых структур данных, разрешите каждому потоку доступ по мере 
необходимости. Воспользуйтесь для обработки условий полного и пустого 
буфера функциями зіеер имакеир. Посмотрите, сколько времени пройдет до 
появления неустранимого состояния состязания. Например, производитель 
может периодически выдавать на печать число, но не чаще, чем раз в минуту, 
поскольку процесс ввода-вывода может повлиять на состояние состязания. 

53. Для получения большего приоритета процесс можно поместить в очередь 
кругового алгоритма планирования больше одного раза. Этого же эффекта 
можно достигнуть, запустив несколько копий программы, каждая из которых 
будет обрабатывать свою часть пула данных. Для начала напишите програм¬ 
му, которая проверяет простоту чисел из списка. Затем разработайте способ 
разрешить одновременный запуск нескольких копий программы, причем 
так, чтобы две копии программы не обращались к одному числу. Удастся ли 
вам ускорить обработку списка, запустив несколько копий программы? 
Имейте в виду, что результат будет зависеть от того, чем еще занят ваш 
компьютер: при отсутствии других процессов улучшения результатов не 
будет, но если параллельно решаются другие задачи, несколько копий про¬ 
граммы позволят получить больший процент времени процессора. 




Глава 3 

Взаимоблокировка 


В компьютерных системах существует большое количество ресурсов, каждый из 
которых в конкретный момент времени может использоваться только одним 
процессом. В качестве таких примеров можно привести принтеры, накопители на 
магнитной ленте и элементы внутренних таблиц системы. Появление двух про¬ 
цессов, одновременно передающих данные па принтер, приведет к печати бессмыс¬ 
ленного набора символов. Наличие двух процессов, использующих один и тот же 
элемент таблицы файловой системы, обязательно станет причиной разрушения 
файловой системы. Поэтому все операционные системы обладают способностью 
предоставлять процессу эксклюзивный доступ (по крайней мере, временный) 
к определенным ресурсам. 

Часто для выполнения прикладных задач процесс нуждается в исключитель¬ 
ном доступе не к одному, а к нескольким ресурсам. Предположим, например, что 
каждый из двух процессов хочет записать отсканированный документ на компакт- 
диск. Процесс А запрашивает разрешение на использование сканера и получает 
его. Процесс В запрограммирован по-другому, поэтому сначала запрашивает устрой¬ 
ство для записи компакт-дисков и также получает его. Затем процесс А обращается 
к устройству для записи компакт-дисков, но запрос отклоняется до тех пор, пока 
это устройство занято процессом В. К сожалению, вместо того чтобы освободить 
устройство для записи компакт-дисков, В запрашивает сканер. В этот момент про¬ 
цессы заблокированы и будут вечно оставаться в этом состоянии. Такая ситуация 
называется тупиком, тупиковой ситуацией или взаимоблокировкой. 

Взаимоблокировки могут возникать между различными машинами. Во многих 
офисах есть локальная сеть, включающая в себя множество компьютеров. Часто 
такие устройства, как сканеры, устройства для записи компакт-дисков, принтеры 
и накопители на магнитной ленте, присоединены к сети как ресурсы совместного 
доступа, то есть доступны любому пользователю на любой машине. Если эти ресур¬ 
сы позволяется резервировать удаленно (то есть с домашней машины пользовате¬ 
ля), может возникнуть аналогичный описанному выше вид тупиковых ситуаций. 
Более сложные ситуации могут стать причиной тупиков, вовлекающих три, четы¬ 
ре и более устройств и пользователей. 

Взаимоблокировки могут произойти во множестве других ситуаций помимо 
запросов выделенных устройств ввода-вывода. В системах баз данных программа 
может оказаться вынужденной заблокировать несколько записей, чтобы избежать 
состояния конкуренции. Если процессѣ блокирует запись Кі, процесс# блоки¬ 
рует запись К2, а затем каждый процесс попытается заблокировать чужую запись, 
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мы также окажемся в тупике. Таким образом, взаимоблокировки появляются при 
работе как с аппаратными, так и с программными ресурсами. 

В этой главе мы рассмотрим тупиковые ситуации более подробно, увидим, как 
они возникают, и изучим некоторые способы, позволяющие предупредить тупико¬ 
вые ситуации или избежать их. Хотя информация о тупиках представлена в контек¬ 
сте операционной системы, они также могут встретиться в системах баз данных 
и во множестве других ситуаций, поэтому этот материал на самом деле применим 
к широкому ряду систем, работающих с несколькими процессами. О взаимобло¬ 
кировках было написано много книг и статей. Библиографии по геме дважды пуб¬ 
ликовались в Орегаііп§ Вузіетз Кеѵіеші и к ним следует обращаться за справочной 
информацией ([246,370]). Несмотря на то что эти библиографии написаны давно, 
большая часть работ по взаимоблокировкам была проделана до 1980 года, поэто¬ 
му данные книги полезны до сих пор. 


Ресурсы 

Система может зайти в тупик, когда процессам предоставляются исключительные 
права доступа к устройствам, файлам и т. д. Чтобы максимально обобщить рассказ 
о взаимоблокировках, мы будем называть объекты предоставления доступа ресур¬ 
сами. Ресурсом может быть аппаратное устройство (например, накопитель на маг¬ 
нитной ленте) или часть информации (например, закрытая запись в базе данных). 
В компьютере существует масса различных ресурсов, к которым могут происхо¬ 
дить обращения. Кроме того, в системе может оказаться несколько идентичных 
экземпляров какого-либо ресурса, например три накопителя на магнитных лентах. 
Если в системе есть несколько экземпляров ресурса, то в ответ на обращение к нему 
может предоставляться любая из доступных копий. Короче говоря, ресурс — это все 
то, что может использоваться только одним процессом в любой момент времени. 

Выгружаемые и невыгружаемые ресурсы 

Ресурсы бывают двух типов: выгружаемые и невыгружаемые. Выгружаемый ресурс 
можно безболезненно забирать у владеющего им процесса. Образцом такого ресур¬ 
са является память. Рассмотрим, например, систему с пользовательской памятью 
размером 32 Мбайт, одним принтером и двумя процессами по 32 Мбайт, каждый 
из которых хочет что-то напечатать. Процесс Л запрашивает и получает принтер, 
затем начинает вычислять данные для печати. Еще не закончив расчеты, он пре¬ 
вышает свой квант времени и выгружается на диск в область подкачки. 

Теперь работает процесс В и безуспешно пытается обратиться к принтеру. В дан¬ 
ный момент мы получили потенциальную тупиковую ситуацию, потому что 
процесс А использует принтер, а процесс В занимает память, и ни один из них не 
может продолжать работу без ресурса, удерживаемого другим. К счастью, можно 
выгрузить (забрать) память у процесса В, переместив его на диск в область под¬ 
качки и скачав с диска в память процесс А. Теперь процесс А может закончить вы¬ 
числения, выполнить печать и затем освободить принтер. Взаимоблокировки не 
происходит. 
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Глава 3. Взаимоблокировка 


Невыгружаемый ресурс, в противоположность выгружаемому, — это такой 
ресурс, который нельзя забрать от текущего владельца, не уничтожив результаты 
вычислений. Если в момент записи компакт-диска внезапно отнять у процесса ус¬ 
тройство для записи и передать его другому процессу, то в результате мы получим 
испорченный компакт-диск. Устройство для записи компакт-дисков не является 
выгружаемым в произвольный момент времени ресурсом. 

Вообще говоря, взаимоблокировки касаются невыгружаемых ресурсов. Потен¬ 
циальные тупиковые ситуации, в которые вовлечен противоположный вид ресур¬ 
сов, обычно можно разрешить с помощью перераспределения ресурсов от одного 
процесса к другому. Поэтому мы сконцентрируем свое внимание на невыгружае¬ 
мых ресурсах. 

Последовательность событий, необходимых для использования ресурса, пред¬ 
ставлена ниже в абстрактной форме. 

1. Запрос ресурса. 

2. Использование ресурса. 

3. Возврат ресурса. 

Если ресурс недоступен, когда он требуется, то запрашивающий его процесс 
вынужден ждать. В некоторых операционных системах при неудачном обращении 
к ресурсу процесс автоматически блокируется и возобновляется только после того, 
как ресурс становится доступным. В других системах запрос ресурса, получивший 
отказ, возвращает код ошибки, тогда вызывающий процесс может подождать не¬ 
много и повторить попытку заново. 

Процесс, чье обращение к ресурсу оказалось неудачным, обычно дальше попа¬ 
дает в короткий цикл: запрос ресурса, затем режим ожидания, потом очередная 
попытка. Хотя этот процесс не блокирован, он во всех смыслах ведет себя, как за¬ 
блокированный, поскольку не может выполнить никакой полезной работы. В даль¬ 
нейшем мы будем предполагать, что когда процессу отказывается в предоставле¬ 
нии ресурса, он переходит в режим ожидания. 

Истинная природа запросов ресурсов сильно зависит от системы. В некоторых 
системах существует системный вызов гециезЪ, позволяющий процессам запраши¬ 
вать ресурсы явно. В других случаях единственный вид ресурсов, известных опе¬ 
рационной системе, — это специальные файлы, которые в каждый данный момент 
времени могут открыть только один процесс. Они открываются с помощью обыч¬ 
ного вызова ореп. Если файл уже используется, вызывающая программа блокиру¬ 
ется до тех пор, пока текущий владелец файла не закроет его. 

Получение ресурса 

Для некоторых видов ресурсов, таких как записи в базе данных, управление ис¬ 
пользованием ресурсов зависит от самих пользовательских процессов. Один из 
способов, делающих возможным пользовательское управление, заключается в при¬ 
соединении семафора к каждому из ресурсов. Все семафоры в исходном состоянии 
равны 1. С тем же успехом можно использовать мьютексы. Три шага, перечислен¬ 
ные выше, выполняются следующим образом: сначала для запроса ресурса исполь- 
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зуется вызов сіомп, примененный к семафору, затем программа использует ресурс 
и, наконец, используется вызов ир для его освобождения. Эти шаги представлены 
в листинге 3.1, а. 


Листинг 3.1. Использование семафора для защиты ресурсов: один ресурс (а); 
два ресурса (б) 

іуребеі іпі зетарИоге: ГурегіеГ ігті зетарИоге: 

зешарИоге гезоигсе_1: зешарИоге гезоигсе_1; 

зешарИоге гезоигсе_2: 


ѵоісі ргосезз_А(ѵоісІ) { 

с1омп(&гезоигсе_1): 
изе_гезоигсе_1(): 
ир(&гезоигсе_1): 

} 


а 


ѵоіР ргосезз_А(ѵоісІ) { 

с1омп(&гезоигсе_1); 
(1омп(&гезоигсе_2): 
изе_Ьо(;Іі_гезоигсе5( ) : 
ир(&гезоигсе_2): 
ир(&гезоигсе_1); 

} 

б 


Иногда процессы нуждаются в двух и более ресурсах. Их можно получать по¬ 
следовательно, как показано в листинге 3.1, б. Если требуется больше двух ресур¬ 
сов, их запрашивают непосредственно один за другим. 

Пока все хорошо. Эта схема работает прекрасно до тех пор, пока она касается 
только одного процесса. Конечно, при наличии всего лишь одного процесса отсут¬ 
ствует необходимость формального приобретения ресурсов, поскольку не возни¬ 
кает соперничества за их использование. 

Теперь рассмотрим ситуацию с двумя процессами Л и Л и двумя ресурсами. 
В листинге 3.2 показаны два сценария: а — оба процесса получают ресурсы в од¬ 
ном и том же порядке; б — они запрашивают ресурсы в разном порядке. Разница 
может показаться несущественной, но это не так. 

В листинге 3.2, а один из процессов запрашивает первый ресурс, опережая вто¬ 
рой процесс. Затем этот же процесс успешно получает второй ресурс и выполняет 
свою работу. Если второй процесс попытается получить ресурс 1 до его освобож¬ 
дения, второй процесс просто будет заблокирован до тех пор, пока не станет дос¬ 
тупен ресурс. 

Другая ситуация представлена в листинге 3.2, б. Может случиться так, что один 
из процессов получит оба ресурса и эффективно блокирует другой процесс до за¬ 
вершения своей работы. Однако также может произойти и то, что процесс А займет 
ресурс 1, а процесс В получит ресурс 2. Теперь, когда они попытаются запросить 
еще по одному ресурсу, каждый из них будет заблокирован. Ни один из двух про¬ 
цессов не сможет когда-либо заработать снова. Это ситуация взаимоблокировки. 

Здесь мы видим, как проявляется несущественное различие в коде програм¬ 
мы — последовательность запросов ресурсов, — которое вызывает разницу между 
работающей программой и программой, завершающейся аварийно, причем с труд¬ 
но обнаруживаемой причиной ошибки. Поскольку взаимоблокировки могут про¬ 
исходить так просто, на поиски методов борьбы с ними было направлено большое 
количество исследований. В этой главе подробно будут обсуждены тупиковые 
ситуации и то, что можно в таких ситуациях предпринять. 




188 


Глава 3. Взаимоблокировка 


Листинг 3.2. Код, не приводящий к тупику (а); коде потенциальной 
взаимоблокировкой (б) 


ТуресІеГ ігтЬ зешарГоге; 
зешарГоге гезоигсе_1: 
зешарРоге гезоигсе_2; 
ѵоіеі ргосезз_А(ѵоіс!) { 

гіоип(&гезоигсе_1) : 
сЫп(&гезоигсе_2); 
изе_ЬоіГ_гезоигсез( ); 
ир(&гезоигсе_2): 
ир(&гезоигсе_1); 

) 

ѵоіеі ргосезз_В(ѵоіс!) { 

с!омп(&гезоигсе_1); 
йомп(&гезоигсе_2): 
изе_ЬоіИ_гезоигсез (); 
ир(&гезоигсе_2): 
ир(&гезоигсе_1); 

) 


ГуресІеГ іпі зешарГоге; 
зетарЬоге гезоигсе_1; 
зешарЬоге гезоигсе_2; 
ѵоіеі ргосезз_А( ѵоіеі) { 

с!омп(&гезоигсе_1): 
с1омі(&гезоигсе_2) ; 
изе_Ьо11і_гезоигсез( ) 
ир(&гезоигсе_2); 
ир(&гезоигсе_1)Г 

} 

ѵоіеі ргосезз_В(ѵоіс!) { 

сЫп(&гезоигсе_2); 
скмі(&гезоигсе_1); 
изе_Ьо11і_гезоигсез() 
ир(&гезоигсе_1): 
ир(&гезоигсе_2); 

) 

б 


Введение 

Взаимоблокировки или тупиковые ситуации формально можно определить так: 

Группа процессов находится в тупиковой ситуации, если каждый процесс из группы 
ожидает события, которое может вызвать только другой процесс из той же группы. 

Так как все процессы находятся в состоянии ожидания, ни один из них не бу¬ 
дет причиной какого-либо события, которое могло бы активировать любой другой 
процесс в группе, и все процессы продолжают ждать до бесконечности. В этой мо¬ 
дели мы предполагаем, что процессы имеют только один поток и что нет прерыва¬ 
ний, способных активизировать заблокированный процесс. Условие отсутствия 
прерываний необходимо, чтобы предотвратить ситуацию, когда тот или иной за¬ 
блокированный процесс активизируется, скажем, по сигналу тревоги и затем при¬ 
водит к событию, которое освободит другие процессы в группе. 

В большинстве случаев событием, которого ждет каждый процесс, является 
возврат какого-либо ресурса, в данный момент занятого другим участником груп¬ 
пы. Другими словами, каждый участник в группе процессов, зашедших в тупик, 
ждет доступа к ресурсу, принадлежащему заблокированному процессу. Ни один 
из процессов не может работать, ни один из них не может освободить какой-либо 
ресурс и ни один из них не может возобновиться. Количество процессов и количе¬ 
ство и вид ресурсов, имеющихся и запрашиваемых, здесь не важны. Результат ос¬ 
тается тем же самым для любого вида ресурсов, аппаратных и программных. 


Условия взаимоблокировки 

В [70] Коффман (СоіТтап) и другие исследователи доказали, что для возникнове¬ 
ния ситуации взаимоблокировки должны выполняться четыре условия: 

1. Условие взаимного исключения. Каждый ресурс в данный момент или от¬ 
дан ровно одному процессу, или доступен. 
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2. Условие удержания и ожидания. Процессы, в данный момент удерживаю¬ 
щие полученные ранее ресурсы, могут запрашивать новые ресурсы. 

3. Условие отсутствия принудительной выгрузки ресурса. У процесса нельзя 
принудительным образом забрать ранее полученные ресурсы. Процесс, вла¬ 
деющий ими, должен сам освободить ресурсы. 

4. Условие циклического ожидания. Должна существовать круговая последова¬ 
тельность из двух и более процессов, каждый из которых ждет доступа к ре¬ 
сурсу, удерживаемому следующим членом последовательности. 

Для того чтобы произошла взаимоблокировка, должны выполниться все эти че¬ 
тыре условия. Если хоть одно из них отсутствует, тупиковая ситуация невозможна. 

Следует отметить, что каждое условие относится к стратегии определения того, 
что в системе позволяется, а что — нет. Может ли данный ресурс быть отдан одно¬ 
временно больше чем одному процессу? Может ли процесс удерживать один ресурс 
и запрашивать второй? Можно ли отнять ресурс у процесса? Может ли существо¬ 
вать циклическое ожидание? Позже мы увидим, как можно разрушать взаимобло¬ 
кировки с помощью сведения «на нет» некоторых из этих условий. 

Моделирование взаимоблокировок 

В [156] Холт (Нок) показал, как можно смоделировать четыре условия возник¬ 
новения тупиков, используя направленные графы. Графы имеют два вида узлов: 
процессы, показанные кружочками, и ресурсы, нарисованные квадратиками. 
Ребро, направленное от узла ресурса (квадрат) к узлу процесса (круг), означа¬ 
ет, что ресурс ранее был запрошен процессом, получен и в данный момент ис¬ 
пользуется этим процессом. На рис. 3.1 , а ресурс К в настоящее время отдан 
процессу А. 



а б в 


Рис. 3.1 . Графы распределения ресурсов: ресурс занят (а); 
запрос ресурса (б); взаимоблокировка (в) 

Ребро, направленное от процесса к ресурсу, означает, что процесс в данный 
момент блокирован и находится в состоянии ожидания доступа к этому ресурсу. 
На рис. ЗА, б процесс В ждет ресурс 5. На рис. 3.1, в мы видим взаимоблокиров¬ 
ку: процесс С ожидает ресурс Т, удерживаемый в настоящее время процессом Л. 
Процесс Л вовсе не намеревается освобождать ресурс Т, потому что он ждет 
ресурс Л, используемый процессом С. Оба процесса будут ждать до бесконечности. 
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Цикл в графе означает наличие взаимоблокировки, циклично включающей про¬ 
цессы и ресурсы (предполагается, что в системе есть по одному ресурсу каждого 
вида). В этом примере циклом является последовательность С-Т-Б-ІІ-С. 

Теперь рассмотрим пример того, как можно использовать графы ресурсов. 
Представим, что у нас есть три процесса: Л, В и С, и три ресурса: Я, 5 и Т. Пос¬ 
ледовательность запросов и возвратов ресурсов для трех процессов показаны на 
рис. 3.2, а—в. Операционная система может запустить любой незаблокированный 
процесс в любой момент времени, значит, она может решить запустить сначала 
процесс А. Процесс А будет выполняться до тех пор, пока не закончит всю свою 
работу, затем будет запущен процесс В до его завершения и, наконец, процесс С. 

Такой порядок не приводит к взаимоблокировке (потому что при нем не воз¬ 
никает соперничества за использование ресурсов), но при нем также вообще нет 
параллельной работы. Кроме запросов и возвратов ресурсов, процессы выполня¬ 
ют вычисления и ввод-вывод данных. Когда процессы работают последовательно, 
невозможна ситуация, при которой один процесс использует процессор, в то вре¬ 
мя как другой ждет завершения операции ввода-вывода. Таким образом, строго 
последовательная работа процессов не может быть оптимальной. С другой сто¬ 
роны, если вообще ни один процесс не выполняет операций ввода-вывода, алго¬ 
ритм «кратчайшая задача — первая» работает лучше, чем циклический, поэтому 
в некоторой обстановке последовательный запуск всех процессов может быть 
наилучшим. 

Теперь предположим, что процессы выполняют как расчеты, так и ввод-вывод, 
так что циклический алгоритм планирования является рациональным. Запросы 
ресурсов могут происходить в порядке, указанном на рис. 3.2, г. Если эти шесть 
запросов будут осуществлены в такой последовательности, в результате мы полу¬ 
чим шесть графов, показанных на рис. 3.2, д—к. После запроса 4 процесс А блоки¬ 
руется в ожидании ресурса 5 (рис. 3.2, з). На двух следующих шагах также блоки¬ 
руются процессы В и С, в конечном счете приводя к циклу и взаимоблокировке на 
рис. 3.2, к. 

Однако, как мы упоминали ранее, операционная система не обязана запускать 
процессы в каком-то особом порядке. В частности, если выполнение отдельного 
запроса приводит в тупик, операционная система может просто приостановить 
процесс без удовлетворения запроса (то есть не выполняя план процесса) до тех 
пор, пока это безопасно. На рис. 3.2 операционная система могла бы приостановить 
процесс В вместо того, чтобы отдавать ему ресурс 5) если бы она знала о предстоя¬ 
щей взаимоблокировке. Работая только с процессами А и С, мы могли бы получить 
порядок запросов ресурсов и их возвратов, продемонстрированный на рис. 3.2, л, 
вместо показанного на рис. 3.2, г. Такая последовательность действий отражена 
графами на рис. 3.2, м—с, и она не приводит к взаимоблокировке. 

После шага с процесс В может получить ресурс 5) потому что процесс А уже 
закончил свою работу, а процесс С имеет в своем распоряжении все необходимые 
ему ресурсы. Даже если затем процесс В, когда он запросит ресурс Т, будет забло¬ 
кирован, система не попадет в тупик. Процесс В всего лишь будет ждать заверше¬ 
ния работы процесса С. 
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АВС 

Запросить К Запросить 3 Запросить Т 

Запросить 3 Запросить Т Запросить К 

Освободить К Освободить 3 Освободить Т 

Освободить 3 Освободить Т Освободить К 

а б в 

1. А запрашивает К 

2. В запрашивает 3 

3. С запрашивает Т 

4. А запрашивает 3 

5. В запрашивает Т 

6. С запрашивает К 
Взаимоблокировка 

г д в ж 




1. А запрашивает К 

2. С запрашивает Т 

3. А запрашивает 3 

4. С запрашивает К 

5. А освобождает К 

6. А освобождает 3 
Нет взаимоблокировки 
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Рис. 3.2. Пример возникновения взаимоблокировки и способы избежать ее 
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Позже в этой главе мы изучим подробный алгоритм для принятия решений о 
распределении ресурсов, которые не приведут к взаимоблокировке. В данный мо¬ 
мент важно понять, что графы ресурсов являются инструментом, позволяющим 
нам увидеть, станет ли заданная последовательность запросов/возвратов ресурсов 
причиной взаимоблокировки. Мы всего лишь шаг за шагом осуществляем запро¬ 
сы и возвраты ресурсов и после каждого шага проверяем граф на содержание цик¬ 
лов. Если они есть, мы зашли в тупик; если нет, значит, взаимоблокировки тоже 
нет. Хотя мы рассматривали графы ресурсов для случая, когда в системе присут¬ 
ствует по одному ресурсу каждого типа, графы также можно построить для обра¬ 
ботки ситуации с несколькими одинаковыми ресурсами [156]. Вообще говоря, при 
столкновении с взаимоблокировками используются четыре стратегии. 

1. Пренебрежение проблемой в целом. Если вы проигнорируете проблему, воз¬ 
можно, затем она проигнорирует вас. 

2. Обнаружение и восстановление. Позволить взаимоблокировке произойти, 
обнаружить ее и предпринять какие-либо действия. 

3. Динамическое избежание тупиковых ситуаций с помощью аккуратного рас¬ 
пределения ресурсов. 

4. Предотвращение с помощью структурного опровержения одного из четы¬ 
рех условий, необходимых для взаимоблокировки. 

Мы по очереди изучим каждый из этих методов в следующих четырех разделах. 


Страусовый алгоритм 

Самым простым подходом является «страусовый алгоритм»: воткните голову в 
песок и притворитесь, что проблема вообще не существует. Различные люди от¬ 
зываются об этой стратегии по-разному. Математики считают ее полностью не¬ 
приемлемой и говорят, что взаимоблокировки нужно предотвращать любой ценой. 
Инженеры спрашивают, как часто встает подобная проблема, как часто система 
попадает в аварийные ситуации по другим причинам и насколько серьезны по¬ 
следствия взаимоблокировок. Если взаимоблокировки случаются в среднем один 
раз в пять лет, а сбои операционной системы, ошибки компилятора и поломки ком¬ 
пьютера из-за неисправности аппаратуры происходят раз в неделю, то большин¬ 
ство инженеров не захотят добровольно уступать в производительности и удоб¬ 
стве для того, чтобы ликвидировать возможность взаимоблокировок. 

Для усиления контраста между этими подходами добавим, что большинство 
операционных систем потенциально страдают от взаимоблокировок, которые даже 
не обнаруживаются, не говоря уже об автоматическом выходе из тупика. Суммар¬ 
ное количество процессов в системе определяется количеством записей в таблице 
процесса. Таким образом, ячейки таблицы процесса являются ограниченным ре¬ 
сурсом. Если системный вызов Тогк получает отказ, потому что таблица целиком 
заполнена, разумно будет, что программа, вызывающая Тогк, подождет какое-то 
время и повторит попытку. 

Теперь предположим, что система ІЖІХ имеет 100 ячеек процессов. Работают 
десять программ, каждой необходимо создать 12 (под)процессов. После образова- 
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ния каждым процессом девяти процессов 10 исходных и 90 новых процессов за¬ 
полнят таблицу целиком. Теперь каждый из десяти исходных процессов попадает 
в бесконечный цикл, состоящий из попыток разветвления и отказов, то есть воз¬ 
никает взаимоблокировка. Вероятность того, что произойдет подобное, минималь¬ 
на, но это могло бы случиться. Должны ли мы отказаться от процессов и вызова 
Тогк, чтобы устранить данную проблему? 

Максимальное количество открытых файлов также ограниченно размером таб¬ 
лицы і-узлов, следовательно, когда таблица заполняется целиком, возникает та же 
самая проблема. Пространство для подкачки файлов на диск является еще одним 
ограниченным ресурсом. Фактически почти каждая таблица в операционной сис¬ 
теме представляет собой ресурс, имеющий пределы. Должны ли мы упразднить 
их все из-за того, что может произойти ситуация, когда в группе из га процессов 
каждый может потребовать 1 /га от целого, а затем попытаться получить еще часть? 

Большая часть операционных систем, включая ІЖІХ и \Ѵішіо\ѵ5, игнорируют 
эту проблему. Они исходят из предположения, что большинство пользователей 
скорее предпочтут иметь дело со случающимися время от времени взаимоблоки¬ 
ровками, чем с правилом, по которому всем пользователям разрешается только 
один процесс, один открытый файл и т. д. Если бы можно было легко устранить 
взаимоблокировки, не возникло бы столько разговоров на эту тему. Сложность 
заключается в том, что цена достаточно высока, и в основном она, как мы вскоре 
увидим, исчисляется в наложении неудобных ограничений на процессы. Таким 
образом, мы столкнулись с неприятным выбором между удобством и корректнос¬ 
тью и множеством дискуссий о том, что более важно и для кого. При всех этих 
условиях трудно найти верное решение. 


Обнаружение и устранение 
взаимоблокировок 

Вторая техника представляет собой обнаружение и восстановление. При исполь¬ 
зовании этого метода система не пытается предотвратить попадание в тупиковые 
ситуации. Вместо этого она позволяет взаимоблокировке произойти, старается 
определить, когда это случилось, и затем совершает некие действия к возврату си¬ 
стемы к состоянию, имевшему место до того, как система попала в тупик. В этом 
разделе мы рассмотрим некоторые из способов обнаружения тупиковых ситуаций 
и выхода из них. 

Обнаружение взаимоблокировки при наличии 
одного ресурса каждого типа 

Начнем с самого простого варианта: в системе существует только один ресурс каж¬ 
дого типа. Подобная система могла бы иметь один сканер, одно устройство для за¬ 
писи компакт-дисков, один плоттер и один накопитель на магнитной ленте, то есть 
не более чем по одному представителю каждого класса. Другими словами, мы ис¬ 
ключаем из рассмотрения системы с двумя одновременно подключенными прин¬ 
терами. Мы обратимся к ним позже и будем использовать другой метод. 
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Для такой системы можно сконструировать граф ресурсов вида, продемонст¬ 
рированного на рис. 3.3. Если этот граф содержит один или больше циклов, зна¬ 
чит, произошла взаимоблокировка и блокирован любой процесс, являющийся 
частью цикла. Если в графе нет циклов, система не попала в тупик. 

В качестве примера более сложной системы, чем те, которые мы рассматрива¬ 
ли до сих пор, обсудим систему с семью процессами, обозначенными буквами от А 
до С, и шестью ресурсами, обозначенными буквами от К до \Ѵ. Состояние систе¬ 
мы, то есть то, какой процесс владеет каким ресурсом и какой ресурс запрашива¬ 
ется процессом в данный момент, соответствует следующему списку: 

1. Процесс А занимает ресурс К и хочет получить ресурс 5. 

2. Процесс В ничего не использует, но хочет получить ресурс Т. 

3. Процесс С ничего не использует, но хочет получить ресурс 5. 

4. Процесс Е> занимает ресурс II и хочет получить ресурсы 5 и Т. 

5. Процесс Е занимает ресурс Т и хочет получить ресурс V. 

6. Процесс Р занимает ресурс ]Ѵ и хочет получить ресурс 5. 

7. Процесс С занимает ресурс V и хочет получить ресурс II. 

Вопрос: «Заблокирована ли эта система и если да, то какие процессы в этом 
участвуют?» 

Чтобы ответить на этот вопрос, мы можем составить граф ресурсов (рис. 3.3, а). 
Этот граф содержит один цикл, который виден при визуальном обследовании. 
Цикл показан на рис. 3.3, б. Изучая его, можно заметить, что процессы ДЕ и С за¬ 
блокированы. Процессы А, С и Р не попали в тупик, потому что любому из них 
можно предоставить ресурс 5, после чего процесс, получивший ресурс, закончит 
свою работу и вернет ресурс. Затем два других процесса по очереди могут полу¬ 
чить ресурс и также успешно выполнить свою работу. 
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Рис. 3.3. Граф ресурсов (а); цикл, извлеченный из а (б) 


Несмотря на то что в простом графе относительно легко зрительно различить 
взаимоблокировку процессов, для использования такой схемы в настоящей систе¬ 
ме нам необходим формальный алгоритм, выявляющий тупики. Известно множе- 
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ство алгоритмов, обнаруживающих циклы в направленных графах. Ниже мы рас¬ 
смотрим простой алгоритм, который изучает граф и завершается или когда нахо¬ 
дит цикл, или когда показывает, что циклов в этом графе не существует. Он ис¬ 
пользует одну структуру данных — список узлов Ь. Во время работы алгоритма на 
ребрах графа будет ставиться метка, говорящая о том, что их уже проверили, это 
делается во избежание повторной проверки. 

Алгоритм работает, осуществляя пять перечисленных ниже шагов. 

1. Для каждого узла А в графе выполняются следующие пять шагов, где N явля¬ 
ется начальным узлом. 

2. Задаем начальные условия: Ь — пустой список, все ребра не маркированы. 

3. Текущий узел добавляем в конец списка А и проверяем количество появле¬ 
ний узла в списке. Если узел присутствует в двух местах, граф содержит 
цикл (записанный в список Ь) и работа алгоритма завершается. 

4. Для заданного узла смотрим, выходит ли из него хотя бы одно немаркирован¬ 
ное ребро. Если да, то переходим к шагу 5, если нет, то переходим к шагу 6. 

5. Случайным образом выбираем любое немаркированное исходящее ребро и 
отмечаем его. Затем по нему переходим к новому текущему узлу и возвра¬ 
щаемся к шагу 3. 

6. Теперь мы зашли в тупик. Удаляем последний узел из списка и возвраща¬ 
емся к предыдущему узлу, то есть тому, который был текущим перед тупи¬ 
ковым узлом. Обозначаем его текущим узлом и возвращаемся к шагу 3. Если 
это первоначальный узел, граф не содержит циклов и алгоритм завершается. 

Этот алгоритм по очереди берет каждый узел в качестве корня того, что, как он 
надеется, окажется деревом, и выполняет в дереве поиск в глубину. Если в про¬ 
цессе обхода алгоритм возвращается к уже встречавшемуся узлу, то он нашел цикл. 
Если алгоритм обходит все ребра из какого-нибудь заданного узла, то он возвраща¬ 
ется к предыдущему узлу. Если он возвращается к корню и не может идти дальше, 
то подграф текущего узла не содержит циклов. Если данное свойство сохраняется 
для всех узлов, значит, полный граф не содержит циклов, а система не заблокирована. 

Чтобы увидеть, как работает описанный алгоритм на практике, воспользуемся 
графом на рис. 3.3, а. Порядок обработки узлов произвольный, поэтому будем ис¬ 
следовать их слева направо и сверху вниз. Тогда алгоритм начнет поиск с узла К, 
затем последовательно с узлов А, В, С, 5, Д Т,Е,Р и т. д. Если мы натолкнемся на 
цикл, алгоритм остановится. 

Мы начинаем с узла Я и инициализируем I как пустой список. Затем добавляем 
узел К в список, переходим к единственно возможному узлу А, и его также добавля¬ 
ем к списку I, получая Ь = [Я,А]. Из узла А следуем к узлу 5, получая Ь = [Д, А, 5]. 
Узел 5 не имеет исходящих ребер, следовательно, это тупик, который заставляет 
нас вернуться к узлу А. Так как у узла А тоже нет немаркированных исходящих 
ребер, мы возвращаемся к узлу К, завершая, таким образом, его исследование. 

Теперь снова начнем поиск, стартуя с узла А и предварительно вернув список I 
в исходное состояние. Эта часть алгоритма тоже быстро остановится, поэтому вы¬ 
полним процесс заново, начиная с узла В. Из узла В алгоритм будет следовать ис¬ 
ходящим ребрам до тех нор, пока не достигнет узла Д в это время список будет 
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таким: I = [В, Т, Е , V, С, П, ГУ]. Теперь мы должны сделать (случайный) выбор. Если 
выбрать узел 5, мы попадаем в тупик и возвращаемся к узлу О. Во второй раз выби¬ 
раем узел Т и получаем измененный список I = [В, Т, Е, V, С, II, 0,Т ]; в этот мо¬ 
мент мы обнаруживаем цикл и останавливаем алгоритм. 

Этот алгоритм далек от оптимального. Лучшая схема описана в [112]. Тем не 
менее он демонстрирует существование алгоритма для обнаружения взаимо¬ 
блокировок. 

Обнаружение взаимоблокировок при наличии 
нескольких ресурсов каждого типа 

Когда в системе существует несколько экземпляров некоторых из ресурсов, для 
обнаружения взаимоблокировок необходим другой метод. Сейчас мы расскажем 
об основанном на матрицах алгоритме, обнаруживающем тупики среди п процессов, 
от Р, до Р„. Пусть тп — это число классов ресурсов, причем в системе Р, ресурсов 
класса 1, Е 2 ресурсов класса 2 и, в общем, Р, ресурсов класса і (где 1 < і < тп). Е — 
это вектор существующих ресурсов. Он передает общее количество имеющихся 
в наличии экземпляров каждого ресурса. Например, если класс 1 представляет со¬ 
бой накопители на магнитных лентах, то Р, = 2 означает, что в системе есть два 
магнитофона. 

В любой момент времени некоторые из ресурсов могут оказаться занятыми 
и, соответственно, недоступны. Пусть А будет вектором доступных ресурсов, 
где Л, равно количеству экземпляров ресурса і, доступных в текущий момент 
(то есть не использующихся). Если оба накопителя на магнитной ленте заняты, 
А) будет равно 0. 

Теперь нам нужны два массива: С — матрица текущего распределения и К — 
матрица запросов, і - я строка в матрице С говорит о том, сколько представителей 
каждого класса ресурсов в данный момент использует процесс Р,. Таким образом, 
Су — это количество экземпляров ресурса у, которое занимает процесс і. Аналогич¬ 
но, Щ — это количество экземпляров ресурса у, которые хочет получить процесс Р,. 
Эти четыре структуры показаны на рис. 3.4. 

Существующие ресурсы 
(Е ѵ Е 2 , Е 3 , Й, Е т ) 

Матрица текущего 
распределения 

С 11 С 12 С 13 ' ' ' С 1т 

С 2 1 С 22 С 23 ■ ■ ' С 2т 

/^.Сщ С п2 С пЗ ' ' ' С пт. 

V _Строка п в данный момент 

предоставлена процессу п 

Рис. 3.4. Четыре структуры данных, необходимые для алгоритма обнаружения тупиков 


Доступные ресурсы 
(А ѵ А 2 , А 3 ,Й,А т ) 
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Для этих четырех структур данных существует важный инвариант. В принци¬ 
пе каждый ресурс или занят, или свободен. Это наблюдение означает, что 

/ = 1 

Другими словами, если сложить все экземпляры ресурса у, предоставленные 
процессам и доступные в данный момент, то в результате мы получим существую¬ 
щее в системе количество экземпляров этого класса ресурсов. 

Алгоритм обнаружения взаимоблокировок основан на сравнении векторов. 
Определим, что для двух векторов А и В отношение А < В означает, что каждый эле¬ 
мент вектора А меньше или равен соответствующему элементу вектора В. Мате¬ 
матически это запишется так: А < В тогда и только тогда, когда А, < В, для 1 <і<т. 

Пусть в исходном положении все процессы не маркированы. По мере продви¬ 
жения алгоритма на процессы будет ставиться отметка, служащая признаком того, 
что они могут закончить свою работу и, следовательно, не находятся в тупике. 
После завершения алгоритма известно, что любой немаркированный процесс на¬ 
ходится в тупиковой ситуации. 

Алгоритм обнаружения тупиков состоит из следующих шагов: 

1. Ищем немаркированный процесс Р„ для которого і-я строка матрицы К 
меньше вектора А или равна ему. 

2. Если такой процесс найден, прибавляем і-ю строку матрицы С к вектору А, 
маркируем процесс и возвращаемся к шагу 1. 

3. Если таких процессов не существует, работа алгоритма заканчивается. 

Завершение алгоритма означает, что все немаркированные процессы, если та¬ 
кие есть, попали в тупик. 

На первом шаге алгоритм ищет процесс, который может доработать до конца. 
Такой процесс характеризуется тем, что все требуемые для него ресурсы должны 
находиться среди доступных в данный момент ресурсов. Тогда выбранный про¬ 
цесс проработает до своего завершения и после этого вернет ресурсы, которые он 
занимал, в общий фонд доступных ресурсов. Затем процесс маркируется как за¬ 
конченный. Если окажется, что все процессы могут работать, тогда ни один из них 
в данный момент не заблокирован. Если некоторые из них никогда не смогут за¬ 
пуститься, значит, они попали в тупик. Несмотря па то что алгоритм не является 
детерминированным (поскольку он может просматривать процессы в любом до¬ 
пустимом порядке), результат всегда одинаков. 

Для иллюстрации работы алгоритма обнаружения тупиков рассмотрим рис. 3.5. 
Здесь у нас есть три процесса и четыре класса ресурсов, которые мы произвольно 
назвали так: накопители на магнитной ленте, плоттеры, сканеры и устройство для 
чтения компакт-дисков. Процесс 1 использует один сканер. Процесс 2 занял два 
накопителя на магнитной ленте и устройство для чтения компакт-дисков. Про¬ 
цесс 3 занимает плоттер и два сканера. Каждый процесс нуждается в дополнитель¬ 
ном устройстве, как показывает матрица К. 

Работая с алгоритмом обнаружения взаимоблокировок, мы ищем процесс, чей 
запрос ресурсов может быть удовлетворен в данной системе. Требования первого 
процесса нельзя выполнить, потому что в системе нет доступного устройства для 
чтения компакт-дисков. Второй запрос также нельзя удовлетворить, так как нет 
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свободных сканеров. К счастью, третий процесс может получить все желаемое, сле¬ 
довательно, он работает, завершается и возвращает все свои ресурсы, давая: 

А =(2 2 2 0). 

С этого момента может выполняться процесс 2, по окончании возвращая свои 
ресурсы в систему. Мы получим: 

А = (4 2 2 1). 

Теперь может работать оставшийся процесс. В этой системе не возникает взаи¬ 
моблокировки. 
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Рис. 3.5. Пример использования алгоритма обнаружения.тупиков 

Теперь обсудим немного измененный вариант ситуации на рис. 3.5. Предполо¬ 
жим, что процесс 3, кроме двух накопителей на магнитной ленте и плоттера, нуж¬ 
дается также и в устройстве для чтения компакт-дисков. Тогда ни один из запро¬ 
сов не может быть удовлетворен, значит, вся система находится в тупике. 

Мы уже знаем, как обнаружить взаимоблокировки, и появляется вопрос: когда 
нужно искать их возникновение. Можно проверять систему каждый раз, когда за¬ 
прашивается очередной ресурс. Это, конечно, позволит обнаружить тупик макси¬ 
мально рано (насколько это возможно), но такая операция может оказаться доро¬ 
гой в смысле времени загрузки процессора. Альтернативный подход: проверять 
систему каждые к минут, или, может быть, только когда степень занятости про¬ 
цессора меньше некоторого граничного значения. Учет загрузки процессора име¬ 
ет смысл, потому что при достаточно большом количестве заблокированных про¬ 
цессов работоспособных процессов в системе останется немного, и процессор часто 
будет незанятым. 

Выход из взаимоблокировки 

Предположим, что наш алгоритм обнаружения взаимоблокировок закончился 
успешно и нашел тупик. Что дальше? Необходимы методы для восстановления 
и получения в итоге снова работающей системы. В этом разделе мы обсудим раз- 
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личные способы ликвидации взаимоблокировок. Однако ни один из них не явля¬ 
ется особо заманчивым. 

Восстановление при помощи 
принудительной выгрузки ресурса 

Иногда можно временно отобрать ресурс у его текущего владельца и отдать его 
другому процессу. Во многих случаях требуется ручное вмешательство, особенно 
в операционных системах пакетной обработки, работающих на мэйнфреймах. 

Например, чтобы забрать лазерный принтер у использующего его процесса, 
оператор может взять все уже напечатанные листы и сложить их в стопку, соблю¬ 
дая последовательность их появления из принтера. Затем процесс можно приос¬ 
тановить (пометить как неработоспособный). В этот момент принтер можно пре¬ 
доставить другому процессу. Когда он закончит работу, можно сложить стопку 
напечатанных листов обратно на выходной поднос принтера и возобновить пер¬ 
воначальный процесс. 

Способность забирать ресурс у процесса, отдавать его другому процессу и затем 
возвращать назад так, что исходный процесс этого не замечает, в значительной мере 
зависит от свойств ресурса. Выйти из тупика таким образом зачастую трудно или 
невозможно. Выбор приостанавливаемого процесса главным образом зависит от 
того, какой процесс владеет ресурсами, которые легко могут быть у него отняты. 

Восстановление через откат 

Если разработчики системы и машинные операторы знают о том, что есть вероят¬ 
ность появления взаимоблокировок, они могут организовать работу таким обра¬ 
зом, чтобы процессы периодически создавали контрольные точки. Создание про¬ 
цессом контрольной точки означает, что состояние процесса записывается в файл, 
в результате чего впоследствии процесс может быть возобновлен из этого файла. 
Контрольные точки содержат не только образ памяти, но и состояние ресурсов, то 
есть информацию о том, какие ресурсы в данный момент предоставлены процес¬ 
су. Для большей эффективности новая контрольная точка должна записываться 
не поверх старой, а в новый файл, так что во время выполнения процесса образу¬ 
ется целая последовательность контрольных точек. 

Когда взаимоблокировка обнаружена, достаточно просто понять, какие ресур¬ 
сы нужны процессам. Чтобы выйти из тупика, процесс, занимающий необходимый 
ресурс, откатывается к тому моменту времени, перед которым он получил данный 
ресурс, для чего запускается одна из его контрольных точек. Вся работа, выпол¬ 
ненная после этой контрольной копии, теряется (например, выходные данные, на¬ 
печатанные позднее контрольной копии, отбрасываются и позже печатаются за¬ 
ново). В результате процесс вновь запускается с более раннего момента, когда он 
не занимал тот ресурс, который теперь предоставляется одному из процессов, по¬ 
павших в тупик. Если возобновленный процесс снова пытается получить данный 
ресурс, ему придется ждать того момента, когда ресурс опять станет доступен. 

Восстановление путем уничтожения процессов 

Грубейший, но одновременно и простейший способ выхода из ситуации взаимо¬ 
блокировки заключается в уничтожении одного или нескольких процессов. Мож¬ 
но уничтожить процесс, находящийся в цикле взаимоблокировки. При небольшом 
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везении другие процессы смогут продолжить работу. Если первое удаление не по¬ 
могает, процедуру можно повторять до тех пор, пока цикл наконец не будет разор¬ 
ван. 

Можно, наоборот, в качестве жертвы выбрать процесс, не находящийся в цикле, 
чтобы он освободил свои ресурсы. При этом подходе уничтожаемый процесс выби¬ 
рается с особой тщательностью, потому что он должен занимать ресурсы, которые 
нужны некоторым процессам в цикле. Например, один процесс может использовать 
принтер и требовать плоттер, другой, наоборот, получил плоттер и запрашивает 
принтер. Оба попали в тупик. Третий процесс может удерживать другие принтер 
и плоттер и успешно работать. Уничтожение третьего процесса приведет к осво¬ 
бождению этих ресурсов и разрушит взаимоблокировку первых двух процессов. 

Там, где это возможно, лучше всего уничтожать те процессы, которые можно 
запустить с самого начала без всяких болезненных эффектов. Например, процеду¬ 
ру компиляции всегда можно повторить заново, поскольку она всего лишь читает 
исходный файл и создает объектный файл. Если процедуру компиляции уничто¬ 
жить в процессе работы, первый ее запуск не повлияет на второй 

С другой стороны, процесс, который обновляет базу данных, не всегда можно 
успешно выполнить во второй раз. Если процесс прибавляет 1 к какой-нибудь за¬ 
писи в базе данных, то его запуск, потом уничтожение, затем повторный запуск 
приведут к прибавлению к записи 2, что неверно. 


Избежание взаимоблокировок 

Рассматривая обнаружение взаимоблокировок, мы неявно предполагали, что ког¬ 
да процесс запрашивает ресурсы, он требует их все сразу (матрица К на рис. 3.4). 
Однако в большинстве систем ресурсы запрашиваются поочередно, по одному. 
Система должна уметь решать, является ли предоставление ресурса безопасным 
или нет, и предоставлять его процессу только в первом случае. Таким образом, воз¬ 
никает новый вопрос: существует ли алгоритм, который всегда может избежать 
ситуации взаимоблокировки, все время делая правильный выбор? Ответом явля¬ 
ется условное «да» — мы можем избежать тупиков, но только если заранее будет 
доступна определенная информация. В этом разделе мы изучим способы уклоне¬ 
ния от взаимоблокировок с помощью аккуратного предоставления ресурсов. 

Траектории ресурсов 

Основные алгоритмы, позволяющие предотвращать взаимоблокировки, базируют¬ 
ся на концепции безопасных состояний. Перед тем как начать описывать алгоритм, 
сделаем небольшое отступление, чтобы взглянуть на идею безопасности с точки 
зрения простого для понимания графического метода. Несмотря на то что графи¬ 
ческий подход не переносится напрямую в пригодный к употреблению алгоритм, 
он дает прекрасное интуитивное понимание существа вопроса. 

На рис. 3.6 представлена модель для системы с двумя процессами и двумя ресур¬ 
сами, например принтером и плоттером. Горизонтальная ось отображает номе¬ 
ра команд, выполняемых процессом А. По вертикальной оси показаны номера 
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команд, выполняемых процессом В. В команде/, процесс Л запрашивает принтер, 
в команде / 2 ему требуется плоттер. Принтер и плоттер освобождаются командами / 3 
и /<, соответственно. Процессу В необходим плоттер с команды / 5 по команду / 7 
и принтер с команды / 6 по команду / 8 . 

Каждая точка на диаграмме представляет совместное состояние двух процес¬ 
сов. Изначально система находится в точке р, когда ни один процесс еще не вы¬ 
полнил ни одну инструкцию. Если планировщик запустит процесс А первым, мы 
попадем в точку д, в которой процесс А выполнил какое-то количество команд, 
а процесс В еще ничего не сделал. В точке д траектория становится вертикальной, 
показывая, что планировщик решил запустить в работу процесс В. При наличии 
одного процессора все отрезки траектории могут быть только вертикальными или 
горизонтальными, но не наклонными. Кроме того, движение всегда происходит на 
север или восток (вверх и вправо), и никогда на юг или запад (вниз и влево), так 
как процессы не могут работать в обратном направлении. 

Когда процесс А пересекает линию /, на отрезке от точки г до точки 5, он запра¬ 
шивает и получает принтер. Когда процесс В достигает точки I, он запрашивает 
плоттер. 



◄-► 

Ч-Плоттер 

Принтер 


Рис. 3.6. Две траектории ресурсов процессов 

Особенно интересны заштрихованные области. Область со штриховкой из верх¬ 
него левого угла в правый нижний представляет промежуток времени, когда оба 
процесса занимают принтер. Правило взаимного исключения делает попадание 
в эту область невозможным. Вторая заштрихованная область соответствует тому, 
что оба процесса используют плоттер, и это также невозможно. 

Если система войдет в прямоугольник, ограниченный линиями /, и / 2 по сторо¬ 
нам и линиями / 5 и / б сверху и снизу, она в конце концов доберется до пересечения 
линий / 2 и / г „ попадет в тупик. В этот момент процесс А запросит плоттер, а процесс В 
потребует принтер, но оба ресурса будут к тому времени заняты. Получается, что 
небезопасным является целый прямоугольник, и в него нельзя входить. В точке С 
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единственно безопасный вариант состоит в том, чтобы оставить процесс Л рабо¬ 
тать до тех пор, пока он не достигнет команды / 4 . После нее любая траектория дой¬ 
дет до точки и. 

Важный для понимания момент заключается в том, что в точке С процесс В за¬ 
прашивает ресурс. Система должна принять решение: предоставлять его или нет. 
Если выдается разрешение, система попадает в небезопасную область и в итоге 
блокируется. Чтобы избежать тупика, нужно приостановить процесс В до тех пор, 
пока процесс А не запросит и не освободит плоттер. 


Безопасные и небезопасные состояния 

Алгоритмы предотвращения взаимоблокировок, которые мы будем изучать дальше, 
используют информацию рис. 3.4. В любой момент времени существует текущее 
состояние, составленное из величин Е,А,С и К. Говорят, что состояние безопас¬ 
но, если оно не находится в тупике и существует некоторый порядок планирова¬ 
ния, при котором каждый процесс может работать до завершения, даже если все 
процессы вдруг захотят немедленно получить свое максимальное количество ре¬ 
сурсов. Проще всего проиллюстрировать эту идею на примере с одним ресурсом. 
На рис. 3.7, а у нас есть состояние, в котором процесс А занимает 3 экземпляра ре¬ 
сурса, но ему в итоге могут потребоваться 9 экземпляров. Процесс В в настоящий 
момент занял 2 экземпляра, но позже ему могут понадобиться всего 4. Процесс С 
владеет двумя, но может потребовать еще 5 штук. В системе есть всего 10 экземп¬ 
ляров данного ресурса, 7 из них уже распределены, три пока свободны. 


01 

01 

5 


Ф 

Ф 

5 



а 


б 


г 


д 


Рис. 3.7. Демонстрация того, что состояние а безопасно 

Состояние на рис. 3.7, а безопасно, потому что существует такая последователь¬ 
ность предоставления ресурсов, которая позволяет завершиться всем процессам. 
А именно, планировщик может просто запустить в работу только процесс В на то 
время, пока он запросит и получит два дополнительных экземпляра ресурса, что 
приведет к состоянию, изображенному на рис. 3.7, б. Когда процесс В закончится, 
мы получим состояние рис. 3.7, в. Затем планировщик может запустить процесс С, 
что со временем приведет нас к ситуации рис. 3.7, г. По завершении процесса С мы 
получим рис. 3.7, д. Теперь процесс А наконец может занять необходимые ему 
шесть экземпляров ресурса и также успешно завершиться. Таким образом, состоя¬ 
ние на рис. 3.7, а является безопасным, потому что система может избежать тупи¬ 
ка с помощью аккуратного планирования процессов. 
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Теперь предположим, что исходное состояние системы продемонстрировано на 
рис. 3.8, а, но в данный момент процесс А запрашивает и получает еще один ресурс, 
приводя к рис. 3.8, б. Сможем ли мы найти последовательность, которая гарантиру¬ 
ет работу системы? Давайте попытаемся. Планировщик может дать проработать 
процессу В до того момента, пока он не запросит все свои ресурсы, как показано 
на рис. 3.8, в. 
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Рис. 3.8. Демонстрация того, что состояние б небезопасно 

В итоге процесс В успешно завершается и мы получаем ситуацию рис. 3.8, г. В этом 
месте мы застряли: в системе осталось только четыре свободных экземпляра ре¬ 
сурса, а каждому из активных процессов необходимо пять. И не существует по¬ 
следовательности действий, гарантирующей успешное завершение всех процессов. 
Следовательно, решение о предоставлении ресурса, которое передвинуло систему 
из положения рис. 3.8, а к рис. 3.8, б , привело ее из безопасного в небезопасное со¬ 
стояние. Если из ситуации рис. 3.8, б запустить процесс А или С, мы не выйдем из 
тупика. Теперь, оглядываясь назад, можно уверенно сказать, что нельзя было вы¬ 
полнять запрос процесса А. 

Следует отметить, что небезопасное состояние само по себе не является тупи¬ 
ком. Начав с рис. 3.8, б, система может проработать некоторое время. Фактически 
даже может успешно завершиться один процесс. Кроме того, возможна ситуация, 
что процесс А сможет освободить один ресурс до следующего своего запроса, по¬ 
зволяя успешно завершиться процессу С, а системе избежать взаимной блокиров¬ 
ки. Таким образом, разница между безопасным и небезопасным состоянием за¬ 
ключается в следующем: в безопасном состоянии система может гарантировать, 
что все процессы закончат свою работу, а в небезопасном состоянии такой гаран¬ 
тии дать нельзя. 


Алгоритм банкира для одного вида ресурсов 

Алгоритм планирования, позволяющий избегать взаимоблокировок, был разра¬ 
ботан Дейкстрой (БцкзЬга, [96]) и носит название алгоритма банкира. Он пред¬ 
ставляет собой расширение алгоритма обнаружения тупиков, о котором было рас¬ 
сказано в разделе «Обнаружение взаимоблокировки при наличии одного ресурса 
каждого типа» данной главы. Модель алгоритма основана на примере банкира 
в маленьком городке, имеющего дело с группой клиентов, которым он выдал ряд 
кредитов. Алгоритм проверяет, ведет ли выполнение каждого запроса к небез- 
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опасному состоянию. Если да, то запрос отклоняется. Если удовлетворение запроса 
к ресурсу приводит к безопасному состоянию, ресурс предоставляется процессу. 
На рис. 3.9, а мы видим четырех клиентов: А, В, С и Д каждый из которых полу¬ 
чил определенное количество единиц кредита (например, 1 единица равна 1 К дол¬ 
ларов). Банкир знает, что не всем клиентам понадобится их максимальный кредит 
немедленно, поэтому он зарезервировал только 10 единиц, а не все 22, которые 
требуются клиентам. (Чтобы провести аналогию с компьютерной системой, счи¬ 
таем, что клиенты — это процессы, единицами, скажем, являются накопители на 
магнитной ленте, а банкир — это операционная система.) 
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Рис. 3.9. Три состояния распределения ресурсов: безопасное (а); 
безопасное (б); небезопасное (е) 


Клиенты вращаются в соответствующем бизнесе, время от времени прося у бан¬ 
ка ссуды (то есть запрашивая ресурсы). В некоторый момент возникает ситуация, 
показанная на рис. 3.9, б. Это состояние безопасно, потому что остались две 
единицы и банкир может задержать все обращения, кроме запросов клиента или 
процесса С, таким образом, позволяя процессу С завершиться и вернуть все четы¬ 
ре отданных ему ресурса. Имея на руках четыре единицы, банкир может отдать их 
или клиенту Д или В, обеспечивая их необходимыми единицами и т. д. 

Рассмотрим, что могло бы произойти, если бы в ситуации на рис. 3.9, б был бы 
удовлетворен запрос еще одной единицы для клиента В. Мы попали бы в состоя¬ 
ние рис. 3.9, в, не являющееся безопасным. Если бы все клиенты вдруг запросили 
максимальные ссуды, то банкир не смог бы их обеспечить и мы попали бы в ту¬ 
пик. Небезопасное состояние не обязано приводить к взаимоблокировке, так как 
клиентам не обязательно потребуется весь доступный кредит, но банкир не может 
рассчитывать на такую ситуацию. 

Алгоритм банкира рассматривает каждый запрос по мере поступления и про¬ 
веряет, приведет ли его удовлетворение к безопасному состоянию. Если да, то про¬ 
цесс получает ресурс, иначе запрос откладывается на более позднее время. Чтобы 
понять, является ли состояние безопасным, банкир проверяет, может ли он предо¬ 
ставить достаточно ресурсов для завершения работы какого-либо клиента. Если 
да, то эти ссуды считаются погашенными, после чего проверяется следующий 
ближайший к пределу займа клиент и т. д. Если, в конце концов, все ссуды могут 
быть погашены, состояние является безопасным и исходный запрос можно удов¬ 
летворить. 
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Алгоритм банкира для нескольких видов ресурсов 

Алгоритм банкира можно обобщить для управления системой с несколькими ви¬ 
дами ресурсов. На рис. 3.10 показано, как он работает. 
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Распределенные ресурсы 


Ресурсы, которые еще нужны 


Рис. 3 . 10 . Алгоритм банкира в системе с несколькими типами ресурсов 

На рис. 3.10 изображены две матрицы. Матрица слева показывает, сколько ре¬ 
сурсов каждого вида занимает в настоящее время каждый из пяти процессов. Мат¬ 
рица справа показывает количество ресурсов, которое нужно добавить каждому 
процессу для успешного завершения. Эти матрицы на рис. 3.4 назывались С и К. 
Как и в случае одного вида ресурсов, процессы должны точно определять необхо¬ 
димое суммарное количество ресурсов до начала работы для того, чтобы система 
могла рассчитать правую матрицу в каждый момент времени. 

Три вектора, изображенные справа от матриц, показывают, соответственно, 
существующие ресурсы (вектор Е), занятые ресурсы (вектор Р) и доступные ре¬ 
сурсы (вектор А). Из вектора Е мы видим, что система имеет шесть накопителей 
на магнитной ленте, три плоттера, четыре принтера и два устройства для чтения 
компакт-дисков. Из них заняты в данный момент пять накопителей, три плоттера, 
два принтера и два устройства для чтения компакт-дисков. Чтобы увидеть этот 
факт, нужно просуммировать четыре столбца, соответствующие ресурсам, в левой 
матрице. Вектор доступных ресурсов является разницей между тем, что присут¬ 
ствует в системе, и тем, что используется в настоящее время. 

Теперь можно изложить алгоритм для проверки безопасности состояния системы. 

1. Ищем в матрице К строку, соответствующую процессу, чьи неудовлетворен¬ 
ные потребности ресурсов меньше или равны вектору А. Если такой строки 
не существует, то система в конце концов попадет в тупик, так как ни один 
процесс не может проработать до успешного завершения. 

2. Допускаем, что процесс, строку которого выбрали в пункте 1, запрашивает 
все необходимые ресурсы (гарантируется, что это возможно) и заканчивает 
работу. Отмечаем этот процесс как завершенный и прибавляем все его ресур¬ 
сы к вектору А. 
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3. Повторяем шаги 1 и 2 до тех пор, пока или все процессы будут помечены 
как завершенные — и состояние в этом случае является безопасным, или 
произойдет взаимоблокировка — тогда состояние небезопасно. 

Если на первом шаге можно выбрать несколько процессов, не имеет значения, 
какой из них будет взят: общий резерв доступных ресурсов или увеличится или, 
в худшем случае, останется неизменным. 

Теперь вернемся к примеру на рис. 3.10. Текущее состояние является безопас¬ 
ным. Предположим, что процесс В в данный момент запрашивает принтер. На этот 
запрос можно ответить положительно, потому что получающееся в результате со¬ 
стояние все еще будет безопасным (процесс .О может доработать до конца, затем 
процесс А или Е, затем остальные). 

Теперь представим, что после того, как процесс В получил один из двух остав¬ 
шихся принтеров, процесс Е потребует последний принтер. Удовлетворение этого 
запроса сократит вектор доступных ресурсов до (1 0 0 0), что приведет к взаимо¬ 
блокировке процессов. Ясно, что следует отложить на время запрос процесса Е. 

Дейкстра (Букзіга) впервые опубликовал алгоритм банкира в 1965 году. С тех 
пор практически каждая книга по операционным системам описывает его в дета¬ 
лях. Различным аспектам этого алгоритма было посвящено бессчетное количество 
статей. К сожалению, мало у кого из авторов хватило смелости показать, что хотя 
алгоритм замечателен в теории, на практике он, по существу, бесполезен, потому 
что нечасто можно определить заранее, сколько ресурсов потребуется процессам 
в будущем. Кроме того, количество процессов не фиксировано, оно динамически 
изменяется по мере входа пользователей в систему и выхода из нее. И, более того, 
ресурсы, про которые считалось, что они доступны, могут внезапно исчезнуть 
(например, накопитель на магнитной ленте может сломаться). Таким образом, на 
практике немногие системы, если зто вообще имеет место, используют алгоритм 
банкира для уклонения от взаимоблокировок. 


Предотвращение взаимоблокировок 

Как мы видели, уклонение от взаимоблокировок, в сущности, невозможно, потому 
что оно требует наличия никому не известной информации о будущих процессах. 
Тогда возникает справедливый вопрос: как же реальные системы избегают попада¬ 
ния в тупики? Для того чтобы ответить на этот вопрос, вернемся назад к четырем 
условиям, сформулированным в [70] (см. раздел «Условия взаимоблокировки» 
данной главы), и посмотрим, смогут ли они дать нам ключ к разрешению проблемы. 
Если мы сможем гарантировать, что хотя бы одно из этих условий никогда не будет 
выполнено, тогда взаимоблокировки станут конструктивно невозможными [150]. 

Атака условия взаимного исключения 

Сначала попробуем атаковать условие взаимного исключения. Если в системе нет 
ресурсов, отданных в единоличное пользование одному процессу, мы никогда не 
попадем в тупик. Но в равной степени понятно, что если позволить двум процес¬ 
сам одновременно печатать данные на принтере, воцарится хаос. Используя под- 
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качку 1 выходных данных для печати, несколько процессов могут одновременно 
генерировать свои выходные данные. В такой модели только один процесс, кото¬ 
рый фактически запрашивает физический принтер, является демоном 2 принтера. 
Так как демон не запрашивает никакие другие ресурсы, для принтера мы можем 
исключить тупики. 

К сожалению, не все устройства поддерживают подкачку данных (таблицу про¬ 
цессов невозможно подкачивать с диска). Кроме того, конкуренция за дисковое 
пространство для подкачки сама по себе может привести к тупику. Что получится, 
если два процесса заполнили своими выходными данными каждый по половине 
дискового пространства, отведенного под подкачку данных, и ни один из них не 
закончил вычисления? Демон может быть запрограммирован так, что начнет пе¬ 
чать, не дожидаясь подкачки всех выходных данных, и принтер тогда простоит 
впустую в том случае, если вычисляющий процесс решил подождать несколько 
часов после первого пакета выходных данных. По этой причине обычно демоны 
программируют так, что они начинают печать только после того, как файл выход¬ 
ных данных целиком станет доступен. В этом случае мы получаем два процесса, 
каждый из которых обработал часть выходных данных, но не все и не может про¬ 
должать вычисления дальше. Ни один из двух процессов никогда не завершится, 
так что произошла взаимоблокировка на диске. 

Тем не менее в этом проглядывает росток часто применяющегося решения. 
Избегайте выделения ресурса, когда это не является абсолютно необходимым, 
и пытайтесь обеспечить ситуацию, в которой фактически претендовать на ресурс 
может минимальное количество процессов. 

Атака условия удержания и ожидания 

Второе из условий, сформулированных Коффманом (СоіТтап) и другими, кажет¬ 
ся, все же подает надежду. Если мы сможем уберечь процессы, занимающие неко¬ 
торые ресурсы, от ожидания остальных ресурсов, мы устраним ситуацию взаимо¬ 
блокировки. Один из способов достижения этой цели состоит в требовании, следуя 
которому любой процесс должен запрашивать все необходимые ресурсы до нача¬ 
ла работы. Если все ресурсы доступны, процесс получит все, что ему нужно, и смо¬ 
жет работать до успешного завершения. Если один или несколько ресурсов заня¬ 
ты, процессу ничего не предоставляется, и он непременно попадает в состояние 
ожидания. 

Первая проблема при этом подходе заключается в том, что многие процессы не 
знают, сколько ресурсов им понадобится, до тех пор, пока не начнут работу. На 
самом деле, если бы они обладали подобными сведениями, то мог бы использо¬ 
ваться и алгоритм банкира. Другая проблема состоит в том, что при этом методе 
ресурсы не будут использоваться оптимально. Возьмем, например, процесс, кото- 

1 Подкачка или спулинг (зрооііпд) — процесс обработки посылаемых на печать документов, кото¬ 
рые сохраняются на диске до момента, когда печатающее устройство сможет их обработать. — 
Примеч. перев. 

2 Демон — скрытая от пользователя служебная программа, работающая в фоновом режиме. — При¬ 
меч. перев. 
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рый читает данные с входной ленты, анализирует их в течение часа и затем пишет 
выходную ленту, а заодно и чертит результаты на плоттере. Если все ресурсы нуж¬ 
но запрашивать заранее, то процесс в течение часа не позволит работать накопите¬ 
лю на магнитной лепте и принтеру. 

И все-таки некоторые пакетные системы на мэйнфреймах требуют, чтобы пользо¬ 
ватели объявляли список всех ресурсов в первой строке каждого задания. Затем 
система немедленно запрашивает все ресурсы и сохраняет их до окончания задачи. 
Этот способ накладывает ограничения на деятельность программиста и занимается 
расточительством ресурсов, зато предотвращает безвыходные тупиковые ситуации. 

Немного отличный метод, позволяющий нарушить условие удержания и ожи¬ 
дания, заключается в наложении следующего требования на процесс, запрашива¬ 
ющий ресурс: процесс сначала должен временно освободить все используемые им 
в данный момент ресурсы. Затем этот процесс пытается сразу получить все необ¬ 
ходимое. 

Атака условия отсутствия принудительной 
выгрузки ресурса 

Попытка исключить третье условие (нет принудительной выгрузки ресурса) по¬ 
дает еще меньше надежд, чем устранение второго условия. Если процесс получил 
принтер и в данный момент печатает выходные данные, насильственное изъятие 
принтера по причине недоступности требуемого плоттера в лучшем случае слож¬ 
но, а в худшем — невозможно. 

Атака условия циклического ожидания 

Остается только одно условие. Циклическое ожидание можно устранить несколь¬ 
кими способами. Один их них: просто следовать правилу, гласящему, что процессу 
дано право только на один ресурс в конкретный момент времени. Если нужен вто¬ 
рой ресурс, процесс обязан освободить первый. Но подобное ограничение неприем¬ 
лемо для процесса, копирующего огромный файл с магнитной ленты на принтер. 

Другой способ уклонения от циклического ожидания заключается в поддерж¬ 
ке общей нумерации всех ресурсов, как показано на рис. 3.11, а. Тогда действует 
следующее правило: процессы могут запрашивать ресурс, когда хотят этого, но все 
запросы должны быть сделаны в соответствии с нумерацией ресурсов. Процесс 
может запросить сначала принтер, затем накопитель на магнитной ленте, но не 
может сначала потребовать плоттер, а затем принтер. 

1. Фотонаборное устройство 

2. Сканер 

3. Плоттер 

4. Накопитель на магнитной ленте 

5. Устройство для чтения компакт-дисков 


а 



Рис. 3.11 . Пронумерованные ресурсы (а); граф ресурсов (б) 
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При выполнении такого правила граф распределения ресурсов никогда не бу¬ 
дет иметь циклов. Покажем, что это так, в случае двух процессов (рис. 3.11, б). 
Мы можем попасть в тупик, только если процесс А запросит ресурс;’, а процесс В 
обратится к ресурсу і. Предположим, что ресурсы і и; различны, значит, они име¬ 
ют разные номера. Если і >;', тогда процессу А не позволяется запрашивать ресурс;', 
потому что его номер меньше, чем номер уже имеющегося у него ресурса. Если же 
і <;, тогда процесс В не может запрашивать ресурс і, потому что этот номер меньше 
номера уже занятого им ресурса. Так или иначе, взаимоблокировка невозможна. 

При работе с несколькими процессами сохраняется та же самая логика. В каж¬ 
дый момент времени один из предоставленных ресурсов будет иметь наивысший 
номер. Процесс, использующий этот ресурс, уже никогда не запросит другие заня¬ 
тые ресурсы. Он или закончит свою работу или, в худшем случае, запросит ресурс 
с еще большим номером, а любой такой ресурс окажется доступен. В итоге процесс 
завершит работу и освободит свои ресурсы. На этот момент сложится ситуация, ког¬ 
да ресурс с высшим номером уже занят каким-то другим процессом, который так¬ 
же сможет закончить свою работу. То есть существует алгоритм, по которому все 
процессы завершатся без попадания в тупик. 

Вариантом этого алгоритма является схема, в которой отбрасывается требова¬ 
ние приобретения ресурсов в строго возрастающем порядке, но сохраняется усло¬ 
вие, что процесс не может запросить ресурсы с меньшим номером, чем уже у него 
имеющиеся. Если процесс на начальной стадии запрашивает ресурсы 9 и 10, затем 
освобождает их, то это равнозначно тому, как если бы он начал работу заново, по¬ 
этому нет причины теперь запрещать ему запрос ресурса 1. 

Несмотря на то что систематизация ресурсов с помощью их нумерации устра¬ 
няет проблему взаимоблокировки, бывают ситуации, когда невозможно найти по¬ 
рядок, удовлетворяющий всех. Когда ресурсы включают в себя области таблицы 
процессов, дисковое пространство для подкачки данных, закрытые записи базы 
данных и другие абстрактные ресурсы, число потенциальных ресурсов и вариан¬ 
тов их применений может быть настолько огромным, что никакая систематизация 
не сможет работать. 

В табл. 3.1 подведены итоги различных методов для предотвращения тупиков. 


Таблица 3.1 . Методы предотвращения тупиков 


Условие 

Метод 

Взаимное исключение 

Удержание и ожидание 

Нет принудительной выгрузки ресурса 
Циклическое ожидание 

Организовывать подкачку данных 

Запрашивать все ресурсы на начальной стадии 
Отобрать ресурсы 

Пронумеровать ресурсы и упорядочить 


Сопутствующие вопросы 

В этом разделе мы обсудим несколько разных вопросов, имеющих отношение к 
взаимоблокировкам. Сюда входят двухфазовое блокирование, тупик без ресурсов 
и «голодание». 
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Двухфазовое блокирование 

Хотя и избежание, и предотвращение блокировок в общем случае не являются 
многообещающими, для отдельных прикладных задач известно немало прекрас¬ 
ных алгоритмов специального назначения. Например, во многих системах баз дан¬ 
ных очень часто выполняется операция, которая просит заблокировать несколько 
записей и затем обновить все заблокированные записи. Когда одновременно рабо¬ 
тает несколько процессов, появляется реальная опасность взаимоблокировки. 

Часто используемый подход называется двухфазовым блокированием. В пер¬ 
вой фазе, то есть на первом этапе, процесс пытается заблокировать все требуемые 
записи по одной за раз. Если операция успешна, процесс переходит ко второму 
этапу, выполняя обновление и освобождение блокировок. Никакой настоящей 
работы на первом этапе не совершается. 

Если во время первой фазы какая-либо необходимая запись оказывается уже 
заблокированной, процесс просто освобождает все свои блокировки и начинает 
первую фазу заново. В некотором смысле этот метод похож на схему, в которой 
запрос всех необходимых ресурсов происходит заранее, или, по крайней мере, пе¬ 
ред тем, как произойдет что-то необратимое. В некоторых версиях двухфазового 
блокирования, если блокировка встретилась во время первой фазы, не происхо¬ 
дит возврата ресурсов и возобновления процесса. В таких версиях может возник¬ 
нуть тупиковая ситуация. 

Но эту стратегию нельзя обобщить. В системах реального времени и системах 
контроля процессов, например, недопустимо частично завершить процесс из-за 
того, что ресурс недоступен, а потом опять начинать все заново. Также недопусти¬ 
мо перезапускать процесс, если он прочел или написал сообщение в сети, обновил 
файлы и сделал что-нибудь еще, что не может быть безопасно повторено. Алго¬ 
ритм работает только в тех ситуациях, когда программист очень тщательно подго¬ 
товил все таким образом, что программу можно остановить в любой точке первой 
фазы и запустить заново. Многие программы не могут быть структурированы 
таким образом. 

Тупики без ресурсов 

До сих пор все наши рассуждения были сконцентрированы на взаимоблокиров¬ 
ках ресурсов. Один процесс хочет получить что-то, что есть у другого процесса, 
и должен ждать, пока тот не отдаст это что-то. Тем не менее взаимоблокировки 
также могут происходить и в других ситуациях, включая те, в которых ресурсы 
вообще не участвуют. 

Например, может случиться, что два процесса заблокировали друг друга: каж¬ 
дый ждет, когда другой выполнит некое действие. Такое часто случается с сема¬ 
форами. В главе 2 мы видели примеры, в которых процесс должен был выполнить 
системный вызов йомп на двух семафорах, обычно на семафоре тиіех и еще на од¬ 
ном. Если эту операцию выполнить в неправильном порядке, то в результате по¬ 
лучится взаимоблокировка. 
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Голодание 

«Голодание» является проблемой, тесно связанной с взаимоблокировкой. В дина¬ 
мических системах постоянно происходят запросы к ресурсам. Необходима неко¬ 
торая политика принятия решений о том, когда, кто и какой ресурс получит. Эта 
политика хотя и кажется разумной, может привести к тому, что некоторые про¬ 
цессы никогда не получат требуемое, хотя они и не будут заблокированы. 

Например, рассмотрим процесс предоставления принтера. Представим, что си¬ 
стема использует некоторый вид алгоритма, гарантирующий, что предоставление 
принтера процессу не приводит к взаимоблокировке. Теперь предположим, что 
несколько процессов одновременно хотят воспользоваться принтером. Какой из 
них должен получить этот ресурс? 

Один возможный алгоритм предоставления ресурсов отдает принтер процессу 
с наименьшим файлом для печати (предполагается, что подобная информация 
доступна). Такой подход максимизирует количество счастливых обслуженных 
клиентов и кажется прекрасным. Теперь рассмотрим, что произойдет в сильно за¬ 
груженной системе, когда один из процессов должен распечатать огромный файл. 
Каждый раз, когда принтер освобождается, система выбирает процесс с наиболее 
коротким файлом. Если в системе есть постоянный поток процессов с небольши¬ 
ми файлами, принтер никогда не будет предоставлен процессу с огромным фай¬ 
лом. Процесс просто «умрет от голода» (будет отложен на неопределенный срок, 
несмотря на то, что даже не будет заблокирован). 

«Голодания» можно избежать, если использовать стратегию распределения ре¬ 
сурсов по принципу «первым пришел — первым обслужен». При таком подходе 
процесс, ожидающий дольше всех, обслуживается следующим. В итоге любой про¬ 
цесс в некоторый момент станет самым старшим в очереди и, таким образом, по¬ 
лучит необходимый ресурс. 


Исследования в области 
взаимоблокировок 

Если когда-либо и существовал предмет, на исследования которого не жалели 
усилий на заре эпохи создания операционных систем, то им были тупиковые 
ситуации. Так происходило по следующей причине: обнаружение взаимобло¬ 
кировок является приятной небольшой проблемой из теории графов, в которую 
имеющие степень в математике студенты могли вонзить свои зубы и переже¬ 
вывать эту проблему в течение 3-х или 4-х лет. Были изобретены самые разно¬ 
образные алгоритмы, каждый последующий все экзотичнее и непрактичнее пре¬ 
дыдущего. В конечном итоге исследования в данной области прекратились. Только 
изредка появляется новая статья, посвященная данной теме (например, [171]). 
Когда операционные системы хотят обнаружить или предотвратить взаимоблоки¬ 
ровку, что некоторые из них и делают, они используют один из методов, обсуж¬ 
давшихся этой главе. 




212 


Глава 3. Взаимоблокировка 


Однако существует еще одно небольшое изыскание по обнаружению распре¬ 
деленных взаимоблокировок. Мы не будем рассматривать его здесь, потому что 
(1) это выходит за рамки данной книги и (2) ничто из этого даже отдаленно не 
практикуется в реальных системах. Кажется, его главная функция — давать рабо¬ 
ту исследователям в области теории графов, в противном случае пополнивших бы 
очереди на бирже труда. 


Резюме 

Взаимоблокировка — это потенциальная проблема любой операционной системы. 
Она происходит, когда в группе процессов каждый получает монопольный доступ 
к некоторому ресурсу и каждому требуется еще один ресурс, принадлежащий дру¬ 
гому процессу в группе. Все процессы оказываются заблокированными, и ни один 
никогда не сможет заработать снова. 

Взаимоблокировки можно избежать, отслеживая, которое состояние является 
безопасным, а которое нет. Безопасное состояние — это то, в котором существует 
последовательность действий, гарантирующая, что все процессы смогут окончить 
свою работу. В небезопасном состоянии таких обязательств дать нельзя. Алгоритм 
банкира избегает тупиков, не выполняя запрос, если тот приводит систему в небез¬ 
опасное состояние. 

Взаимоблокировки можно предотвратить структурно, построив систему таким 
образом, что тупиковая ситуация никогда не возникнет по построению. Например, 
если позволить процессу использовать только один ресурс в любой момент време¬ 
ни, не выполнится необходимое для возникновения тупиков условие цикличес¬ 
кого ожидания. Взаимоблокировки также можно предотвратить, если перенуме¬ 
ровать все ресурсы и затем требовать от процессов создания запросов в строго 
возрастающем порядке. «Голодания» можно избежать, если использовать страте¬ 
гию распределения ресурсов «первым пришел — первым обслужен». 


Вопросы 

1. Приведите пример взаимоблокировки, взятый из области политики. 

2. Студенты, работая на персональных компьютерах в лаборатории, посылают 
свои файлы для печати на сервер, записывающий файлы в область подкач¬ 
ки данных на жесткий диск. При каких условиях может произойти взаимо¬ 
блокировка, если дисковое пространство для подкачки данных печати огра¬ 
ничено? Как можно избежать взаимоблокировки? 

3. Какие ресурсы в предыдущем вопросе являются выгружаемыми, а ка¬ 
кие — нет? 

4. В листинге 3.1 ресурсы возвращаются в порядке, обратном их получению. 
Будет ли с тем же успехом работать эта схема, если возвращать их в другом 
порядке? 
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5. Рисунок 3.1 демонстрирует концепцию графа ресурсов. Существует ли 
недопустимый граф, то есть такой граф, структура которого нарушает мо¬ 
дель, использованную нами для распределения ресурсов? Если да, приве¬ 
дите пример. 

6. Обсуждая страусовый алгоритм, мы упоминали про возможность того, что 
ячейки в таблице процессов или в других системных таблицах заполнятся 
целиком. Можете ли вы предложить метод, дающий возможность систем¬ 
ному администратору вывести систему из такой ситуации? 

7. Рассмотрим рис. 3.2. Предположим, что на шаге п процесс С вместо ресурса К 
запрашивает ресурс 5. Приведет ли это к взаимоблокировке? А если он за¬ 
просит оба ресурса, то есть и 5, и К ? 

8. На перекрестках со знаком ЗТОР по всем четырем направлениям существу¬ 
ет правило: каждый водитель уступает дорогу машине справа. Это правило 
не применимо, когда к перекрестку одновременно подъезжают четыре авто¬ 
буса. К счастью, люди иногда способны действовать более разумно, чем ком¬ 
пьютеры, и подобная проблема обычно решается, когда один из водителей 
подает знак ехать машине слева от себя. Можете ли вы провести аналогию 
между таким образом действий и способами выхода из тупиков, описанны¬ 
ми в разделе «Выход из взаимоблокировки»? Почему эту ситуацию так труд¬ 
но применить к компьютерной системе? 

9. Предположим, что на рис. 3.4 Су + Ку < Е) для некоторых і. Какое значение 
имеет это неравенство для всех процессов, заканчивающихся без блокировок? 

10. Все траектории на рис. 3.6 горизонтальны или вертикальны. Можете ли вы 
представить себе условия, при которых также были бы возможны наклон¬ 
ные траектории? 

И. Может ли схема траектории ресурсов на рис. 3.6 также использоваться для 
иллюстрации проблемы тупиков с тремя процессами и тремя ресурсами? 
Если да, то как? Если нет, то почему? 

12. Теоретически график траектории ресурсов мог бы использоваться для из¬ 
бежания тупиков. При умном планировании операционная система могла 
бы уклоняться от попадания в небезопасные области. Предложите практи¬ 
ческую проблему с фактическим выполнением этого. 

13. Внимательно посмотрите на рис. 3.9, б. Если процесс В запросит еще одну 
единицу, приведет это к безопасному состоянию или к небезопасному? Что 
будет, если запрос поступит от процесса С вместо процесса Б? 

14. Может ли система находиться в состоянии, не являющимся ни состоянием 
взаимоблокировки, ни безопасным состоянием? Если да, приведите пример. 
Если нет, докажите, что все состояния либо являются тупиками, либо они 
безопасны. 

15. Пусть в системе существует два процесса и три одинаковых ресурса. Каж¬ 
дому процессу требуется максимум два ресурса. Возможна ли взаимобло¬ 
кировка? Объясните ваш ответ. 
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16. Снова рассмотрим предыдущий вопрос, но пусть теперь в системе будет р 
процессов, каждому нужно максимум т ресурсов, а всего доступно в систе¬ 
ме г ресурсов. Какое условие должно выполняться, чтобы в системе не было 
тупиков? 

17. Предположим, что процесс Л на рис. 3.10 запрашивает последний накопи¬ 
тель на магнитной ленте. Приведет ли это к взаимоблокировке? 

18. У компьютера есть шесть накопителей на магнитной ленте и п процессов, 
соревнующихся за право их использовать. Каждому процессу может потре¬ 
боваться два накопителя. При каких значениях п в системе не будет тупиков? 

19. Алгоритм банкира работает в системе, где есть т классов ресурсов и п про¬ 
цессов. При тип стремящихся к бесконечности количество операций, ко¬ 
торое нужно выполнить для проверки безопасности состояния, пропорцио¬ 
нально т а п ь . Что представляют собой величины аиЬ ? 

20. В системе есть четыре процесса и пять ресурсов, которые можно предоста¬ 
вить процессам. Текущее распределение ресурсов и максимальное их коли¬ 
чество, необходимое процессам, следующее: 


Предоставлено Максимум Доступно 


Процесс А 

10211 

112 13 

00x11 

Процесс В 

20110 

222 1 0 


Процесс С 

110 10 

2 13 10 


Процесс Р 

11110 

11221 



Каково наименьшее значение величины х, при котором это состояние явля¬ 
ется безопасным? 

21. Распределенная система, использующая почтовые ящики, имеет два прими¬ 
тива межпроцессного взаимодействия: зепсі (послать) и гесеіѵе (получить). 
Второй примитив указывает процесс, от которого следует получить сообще¬ 
ние, и блокируется, если сообщения от процесса недоступны, даже несмот¬ 
ря на то, что могут ожидаться сообщения от других процессов. Здесь нет 
общих ресурсов, но процессам необходимо часто связываться друг с другом 
относительно других вопросов. Возможна ли взаимоблокировка? Аргумен¬ 
тируйте ответ. 

22. Есть два процесса А мВ, каждому нужны три записи в базе данных: 1, 2 и 3. 
Если процесс А обратится к записям в порядке 1, 2, 3 и процесс В запросит 
их в том же самом порядке, взаимоблокировка невозможна. Однако если 
процесс В обратится к записям в порядке 3, 2,1, то появление взаимоблоки¬ 
ровки станет возможным. При наличии трех ресурсов в системе есть 3! (что 
равно 6) возможных комбинации того, как каждый процесс может запросить 
ресурсы. Какая часть от количества всех комбинаций гарантирует отсутствие 
тупиков в системе? 

23. Теперь рассмотрим ситуацию предыдущего вопроса, но с использованием 
двухфазового блокирования. Устранит ли это потенциальную возможность 
взаимоблокировок? Обладает ли оно какими-либо другими нежелательны¬ 
ми характеристиками? Если да, то какими? 
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24. Сотни одинаковых процессов в электронных системах перевода фондов ра¬ 
ботают следующим образом. Каждый процесс читает входную строку, опре¬ 
деляющую количество денег для перевода, кредитовый и дебетовый счета. 
Затем он блокирует оба счета и переводит деньги, а после завершения пере¬ 
вода снимает блокировку. При параллельно работающем большом количе¬ 
стве процессов существует опасность, что, имея заблокированным счетх, 
процесс будет неспособен заблокировать счет у, потому что счет у уже ока¬ 
жется заблокированным процессом, в данный момент ожидающим счет .г. 
Разработайте схему действия, избегающую взаимоблокировок. Не осво¬ 
бождайте запись счета до тех пор, пока вы не закончите транзакцию. (Иначе 
говоря, не позволяются решения, в которых один счет блокируется и затем 
немедленно освобождается, если другие счета заблокированы.) 

25. Один из способов предотвращения взаимоблокировок заключается в нару¬ 
шении условия удержания и ожидания. В тексте главы предлагалось, что 
перед запросом нового ресурса процесс должен сначала освободить все ресур¬ 
сы, уже занятые им (считается, что это возможно). Однако если действовать 
таким образом, появляется опасность, что процесс может получить новый 
ресурс, но при этом потерять некоторые из уже имеющихся, необходимых 
для завершения процесса. Усовершенствуйте эту схему. 

26. Студент, получивший работу в области взаимоблокировок, придумал следу¬ 
ющий замечательный метод устранения тупиков. Когда процесс запрашива¬ 
ет ресурс, он указывает временной предел. Если процесс блокируется из-за 
недоступности ресурса, запускается таймер. Если временной предел превы¬ 
шен, процесс разблокируется, и ему позволяется работать снова. Если бы вы 
были профессором, какую бы оценку вы поставили за этот план, и почему? 

27. Золушка и Принц расторгают брак. Чтобы разделись свое имущество, они 
согласились на следующий алгоритм. Каждое утро любой из них может по¬ 
слать письмо адвокату другого, в котором запрашивает один предмет иму¬ 
щества. Поскольку день уходит на доставку писем, они пришли к согла¬ 
шению, что если оба обнаруживают, что запросили один и тот же предмет 
в один и тот же день, на следующий день они посылают письмо с отменой 
запроса. Среди прочего имущества у них есть собака Буфер, конура Буфера, 
их канарейка Твитер и клетка Твитера. Животные любят свои жилища, по¬ 
этому было принято соглашение, что любой вариант раздела имущества, от¬ 
деляющий животное от его дома, является недействительным, после кото¬ 
рого весь раздел имущества требуется начать заново. И Золушка, и Принц 
отчаянно хотят заполучить Буфера. Поскольку они могут уехать (отдельно 
друг от друга) в отпуск, каждый супруг запрограммировал персональный 
компьютер для обработки переговоров. Когда они возвращаются из отпус¬ 
ков, компьютеры все еще ведут переговоры. Почему? Возможна ли взаимо¬ 
блокировка? Возможно ли «голодание»? Аргументируйте ответ. 

28. Студент, специализирующийся на антропологии и изучавший в качестве не¬ 
основной дисциплины вычислительную технику, начал исследовательский 
проект, чтобы увидеть, могут ли африканские бабуины обучаться ситуации 
со взаимоблокировками. Он определяет место глубокого каньона и при- 
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крепляет канат через него, так что бабуины могут переправиться через про¬ 
пасть на руках. Несколько бабуинов могут переправляться одновременно 
при условии, что они все будут двигаться в одном направлении. Если бабуи¬ 
ны, перемещающиеся в западном и восточном направлении, одновременно 
залезут на канат, в результате получится взаимоблокировка (бабуины заст¬ 
рянут на середине), потому что один бабуин не может перелезть через друго¬ 
го, пока они оба висят над каньоном. Если бабуин хочет пересечь каньон, он 
должен проверить, что в данный момент нет других бабуинов, пересекаю¬ 
щих каньон в противоположном направлении. Напишите программу, ис¬ 
пользующую семафоры, избегающую взаимоблокировок. Не думайте о груп¬ 
пах бабуинов, движущихся на восток, целиком остановитесь на бабуинах, 
движущихся на запад. 

29. Решите еще раз предыдущую задачу, но теперь попробуйте избежать «го¬ 
лодания». Когда бабуин, желающий перейти на восток, подходит к канату 
и видит бабуина, пересекающего каньон на запад, он ждет освобождения 
каната. Но с этого момента бабуинам с востока не разрешается начинать пе¬ 
реход каньона до тех пор, пока, по крайней мере, один бабуин не перейдет 
каньон в противоположном направлении. 

30. Составьте программу, моделирующую алгоритм банкира. Ваша программа 
должна выполнять цикл по каждому клиенту банка, получая запрос и оце¬ 
нивая, является он безопасным или нет. Выведите протокол запросов и при¬ 
нятых решений в файл. 




Глава 4 

Управление памятью 


Память представляет собой важный ресурс, требующий тщательного управления. 
Несмотря на то что в наши дни память среднего домашнего компьютера в тысячи 
раз превышает ресурсы ІВМ 7094 — машины, бывшей в начале 60-х годов самой 
мощной в мире, — программы все равно увеличиваются в размере быстрее, чем 
память. Перефразированный закон Паркинсона гласит: «Программы расширяют¬ 
ся, стремясь заполнить весь объем памяти, доступный для их поддержки». В этой 
главе мы рассмотрим, как операционная система управляет памятью. 

В идеале каждый программист хотел бы иметь неограниченную в размере и ско¬ 
рости память, при этом также являющуюся энергонезависимой, то есть сохраняю¬ 
щую свое содержимое при выключении электричества — отключении от источ¬ 
ников питания. Раз уж мы взялись за эту тему, то почему бы заодно не помечтать 
о дешевой памяти? К сожалению, технологии не могут обеспечить подобную па¬ 
мять. Вследствие этого память в компьютерах имеет иерархическую структуру. 
Небольшая часть ее представляет собой очень быструю, дорогую, энергозависи¬ 
мую (то есть теряющую информацию при выключении питания) кэш-память. Кро¬ 
ме того, компьютеры обладают десятками мегабайт среднескоростной, имеющей 
среднюю цену, также энергозависимой оперативной памяти ОЗУ (НАМ) и десят¬ 
ками или сотнями гигабайт медленного, дешевого, энергонезависимого простран¬ 
ства на жестком диске. Одной из задач операционной системы является коорди¬ 
нация использования всех этих составляющих памяти. 

Часть операционной системы, отвечающая за управление памятью, называется 
модулем управления памятью или менеджером памяти. Он следит за тем, какая 
часть памяти используется в данный момент, а какая — свободна; при необходимос¬ 
ти выделяет память процессам и по их завершении освобождает ресурсы; управляет 
обменом данных 1 между оперативной памятью и диском, если память слишком 
мала для того, чтобы вместить все процессы. 

В этой главе мы изучим несколько различных схем управления памятью, от 
самой простой до весьма сложной и запутанной. Но начнем мы с самого начала, 
и прежде всего рассмотрим наиболее элементарную систему управления памятью, 
а затем постепенно перейдем ко все более и более совершенным конструкциям. 

В первой главе мы обращали внимание на то, что в компьютерном мире исто¬ 
рия имеет тенденцию к повторениям, и хотя простейшие схемы управления памя¬ 
тью больше не используются в настольных персональных компьютерах, они все 

1 Последняя операция называется подкачкой данных с диска или свопингом (з\ѵарріп§). — Примеч. перев. 
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еще работают в карманных компьютерах, встроенных системах и смарт-картах. 
Именно по этой причине их до сих пор стоит изучать. 


Основное управление памятью 

Системы управления памятью можно разделить на два класса: перемещающие 
процессы между оперативной памятью и диском во время их выполнения (то есть 
осуществляющие подкачку процессов целиком (5\ѵарріп§) или использующие 
страничную подкачку (рафп§)) и те, которые этого не делают. Второй вариант 
проще, поэтому начнем с него, а два упомянутых выше вида подкачки мы изучим 
позже в этой же главе. Читая главу 4, следует помнить, что обычный и постранич¬ 
ный варианты подкачки в значительной степени являются искусственными про¬ 
цессами, вызванными отсутствием достаточного количества оперативной памяти 
для одновременного хранения всех программ. Если же когда-нибудь оператив¬ 
ная память настолько увеличится в размерах, что ее будет достаточно, аргументы 
в пользу той или иной схемы управления памятью могут стать устаревшими. 

С другой стороны, выше уже упоминалось, что программное обеспечение растет 
еще быстрее, чем память; поэтому вполне возможно, что потребность в рациональ¬ 
ном и эффективном управлении памятью будет существовать всегда. В 80-е годы 
многие университеты использовали системы разделения времени для работы 
десятков (более-менее довольных) пользователей на машинах ѴАХ с объемом 
памяти 4 Мбайт. Сейчас компания МісгозоІД рекомендует для индивидуальной 
работы в системе )ѴіпсІо\Ѵ5 2000 устанавливать на компьютер, по меньшей мере, 
64 Мбайт оперативной памяти. Дальнейшее развитие в сторону мультимедийных 
систем накладывает еще большие требования на память. Таким образом, весьма 
вероятно, что качество управления этой частью компьтера будет актуальным по 
крайней мере в течение следующего десятилетия. 

Однозадачная система без подкачки на диск 

Самая простая из возможных схем управления памятью заключается в том, что 
в каждый конкретный момент времени работает только одна программа, при этом 
память разделяется между программами и операционной системой. На рис. 4.1 
показаны три варианта такой схемы. Операционная система может находиться 
в нижней части памяти, то есть в ОЗУ (оперативное запоминающее устройство, 
КАМ (Капсіот А ссека Метогу — память с произвольным доступом)) — см. рис. 4.1, а. 
Или же операционная система может располагаться в самой верхней части памя¬ 
ти — в ПЗУ (постоянное запоминающее устройство, КОМ (Кеаб-Опіу Метогу — 
память только для чтения)), как продемонстрировано на рис. 4.1, б. И третий спо¬ 
соб: драйверы устройств могут находиться наверху в ПЗУ, а остальная часть сис¬ 
темы — в ОЗУ, расположенной ниже, как показано на рис. 4.1, в. Первая модель 
раньше применялась на мэйнфреймах и мини-компьютерах, но в настоящее время 
практически не употребляется. Вторая схема сейчас используется на некоторых 
карманных компьютерах и встроенных системах, а третья модель устанавливалась 
на ранних персональных компьютерах (например, работающих с М5-005), при 
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этом часть системы в ПЗУ носила название ВЮ5 (Вазіс Іприі ОиТриі Зузіет — 
базовая система ввода-вывода). 

Когда система организована таким образом, в каждый конкретный момент 
времени может работать только один процесс. Как только пользователь набирает 
команду, операционная система копирует запрашиваемую программу с диска в па¬ 
мять и выполняет ее, а после окончания процесса выводит на экран символ при¬ 
глашения и ждет новой команды. Получив команду, она загружает новую програм¬ 
му в память, записывая ее поверх предыдущей. 



ОхРРР 

Операционная 
система в ПЗУ 


Драйверы 
устройств 
в ПЗУ 

Программа 

пользователя 
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пользователя 




пользователя 



Операционная 
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Рис. 4.1. Три простейшие модели организации памяти при наличии операционной системы 
и одного пользовательского процесса. Существуют также и другие возможные варианты 

Многозадачность с фиксированными разделами 

Однозадачные системы сложно использовать где-либо еще, кроме простейших 
встроенных систем. Большинство современных систем позволяет одновременный 
запуск нескольких процессов. Наличие нескольких процессов, работающих в один 
момент времени, означает, что когда один процесс приостановлен в ожидании 
завершения операции ввода-вывода, другой может использовать центральный 
процессор. Таким образом, многозадачность увеличивает загрузку процессора. 
Сетевые серверы всегда имеют возможность одновременной работы нескольких 
процессов (для разных клиентов), но и большинство клиентских машин (то есть 
настольных компьютеров) в наши дни также имеют эту возможность. 

Самый легкий способ достижения многозадачности представляет собой про¬ 
стое разделение памяти на п (возможно, не равных) разделов. Такое разбиение 
можно выполнить, например, вручную при запуске системы. 

Когда задание поступает в память, его можно расположить во входной очереди 
к наименьшему разделу, достаточно большому для того, чтобы вместить это зада¬ 
ние. Так как в данной схеме размер разделов неизменен, все пространство в разде¬ 
ле, не используемое работающим процессом, пропадает. На рис. 4.2, а показано, как 
выглядит система с фиксированными разделами и отдельными очередями вход¬ 
ных заданий. 

Недостаток сортировки входящих работ по отдельным очередям становится 
очевидным, когда к большому разделу нет очереди, в то время как к маленькому 
выстроилось довольно много задач; в нашем примере на рис. 4.2, а это разделы 1 и 3. 
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Небольшие задания должны ждать своей очереди, чтобы попасть в намять, и это 
все несмотря на то, что свободна основная часть памяти. Альтернативная схема 
заключается в организации одной общей очереди для всех разделов, как показано 
на рис. 4.2, б\ как только раздел освобождается, задачу, находящуюся ближе всего 
к началу очереди и подходящую для выполнения в этом разделе, можно загрузить 
в него и начать ее обработку. Поскольку нежелательно тратить большие разделы 
на маленькие задачи, существует другая стратегия. Она заключается в том, что 
каждый раз после освобождения раздела происходит поиск в очереди наибольше¬ 
го из помещающихся в этом разделе заданий, и именно это задание выбирается 
для обработки. Заметим, что последний алгоритм дискриминирует мелкие зада¬ 
чи, как недостойные того, чтобы под них отводился целый раздел, хотя обычно 
крайне желательно предоставить для наименьших задач (часто интерактивных) 
лучшее, а не худшее обслуживание. 


Несколько 
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ООО— 


Раздел 4 


Раздел 3 


Раздел 2 
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Рис. 4.2. Фиксированные разделы памяти с отдельными входными очередями для каждого 
раздела (а); фиксированные разделы памяти с одной очередью на вход (б) 


Выйти из положения можно, создав хотя бы один маленький раздел памяти, 
который позволит выполнять мелкие задания без долгого ожидания освобожде¬ 
ния больших разделов. 

При другом подходе устанавливается следующее правило: задачу, имеющую 
право быть выбранной для обработки, можно пропустить не больше к раз. Каж¬ 
дый раз, когда через нее перескакивают, к счетчику добавляется единица. Когда 
значение счетчика становится равным к, игнорировать задачу более нельзя. 

Подобная схема, где утром оператор задает фиксированные разделы и пос¬ 
ле этого они не изменяются, в течение многих лет использовалась в системах 
05/360 на больших мэйнфреймах компании ІВМ. Она носила название МРТ 
(Микірго§гаттіп§ ѵѵіПі а Ріхесі питЬег о Г Так к 5 — мультипрограммирование с фик¬ 
сированным количеством задач, или 05/МРТ). Она легка для понимания и не 
менее проста в исполнении: входящее задание стоит в очереди до тех пор, пока не 
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станет доступным соответствующий раздел, затем оно загружается в этот раздел 
памяти и там работает до завершения процесса. Сейчас очень мало (если они вооб¬ 
ще сохранились) операционных систем, поддерживающих такую модель. 

Моделирование многозадачности 

При использовании многозадачности повышается эффективность загрузки цент¬ 
рального процессора. Грубо говоря, если средний процесс выполняет вычисления 
только 20 % от того времени, которое он находится в памяти, то при присутствии 
в памяти одновременно пяти процессов центральный процессор должен быть за¬ 
нят все время. Эта схема слишком оптимистична в отличие от реальной ситуации, 
поскольку она предполагает, что все пять процессов никогда не ожидают заверше¬ 
ния операции ввода-вывода одновременно. 

Более совершенная модель рассматривает эксплуатацию центрального про¬ 
цессора с точки зрения теории вероятности. Предположим, что процесс прово¬ 
дит часть р своего времени в ожидании завершения операции ввода-вывода. 
Если в памяти находится одновременно п процессов, вероятность того, что все 
п процессов ждут ввод-вывод (в этом случае центральный процессор будет бездей¬ 
ствовать), равна р". Тогда степень загрузки центрального процессора будет выра¬ 
жаться формулой: 

Степень загрузки центрального процессора = 1 - р п . 

На рис. 4.3 показана зависимость степени использования центрального про¬ 
цессора от числа п, называемого степенью многозадачности. 



Рис. 4.3. Зависимость степени загрузки центрального процессора 
! от количества процессов в памяти 

Из рисунка понятно, что если процессы проводят 80 % своего времени в ожи¬ 
дании завершения операции ввода-вывода, то для того, чтобы получить потерю 
времени процессора ниже 10 %, в памяти должны одновременно находиться, по 
меньшей мере, 10 процессов. Когда вы представляете себе, что интерактивный 
процесс, ожидая, пока пользователь напечатает что-либо на терминале, находится 
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в состоянии ожидания ввода-вывода, должно быть ясно, что время ожидания вво¬ 
да-вывода, равное 80 % и больше, не является необычным. Но даже в системах па¬ 
кетной обработки процессы, выполняющие ввод-вывод в основном с диска, часто 
имеют такой же или больший процент. 

Нужно отметить, что описанная выше вероятностная модель является доволь¬ 
но грубым приближением. Она неявно предполагает, что все п процессов незави¬ 
симы, то есть допустима следующая ситуация: в памяти находятся пять процес¬ 
сов, из них три работают, а два ждут. Но когда в системе присутствует один- 
единственный центральный процессор, он не может одновременно обрабатывать 
три процесса, поэтому уже готовый к работе процесс обязан ждать освобождения 
процессора. Таким образом, в реальности процессы не являются независимыми. 
Более аккуратную модель можно построить с использованием теории организа¬ 
ции очередей, но общая идея, на которую мы обратили внимание — многозадач¬ 
ность позволяет процессам использовать центральный процессор тогда, когда при 
других обстоятельствах он бы бездействовал, — конечно, останется в силе, даже 
если кривые на рис. 4.3 немного изменятся. 

Хотя модель на рис. 4.3 очень проста, тем не менее она позволяет сделать оп¬ 
ределенный, хотя и приблизительный, прогноз относительно производительно¬ 
сти центрального процессора. Например, предположим, что компьютер имеет 
32 Мбайт памяти, 16 Мбайт отдано операционной системе, а каждая программа 
пользователя занимает по 4 Мбайт. При таких заданных размерах одновременно 
можно загрузить в память четыре пользовательские программы. При 80 % време¬ 
ни на ожидание ввода-вывода в среднем мы получим загруженность процессо¬ 
ра (игнорируя издержки операционной системы) равной 1-0,8 4 , или около 60 %. 
Добавление еще 16 Мбайт памяти позволит системе повысить степень многоза¬ 
дачности от четырех до восьми и таким образом повысить степень загрузки 
процессора до 83 %. Другими словами, дополнительные 16 Мбайт увеличат про¬ 
изводительность на 38 %. 

Еще 16 Мбайт могли бы повысить загрузку процессора с 83 до 93 %, таким об¬ 
разом, увеличив производительность всего лишь на 12 %. С помощью этой модели 
владелец компьютера может решить, что первые 16 Мбайт оперативной памяти — 
это хорошее вложение капитала, а вторые — нет. 

Анализ производительности 
многозадачных систем 

Описанную выше модель также можно применить для анализа систем пакетной 
обработки. Например, рассмотрим компьютерный центр, в котором среднее время 
ожидания ввода-вывода задачами равно 80 %. Однажды утром подаются на выпол¬ 
нение 4 задания, как показано на рис. 4.4, а. Первая задача, поступившая в 10 утра, 
требует 4 мин работы процессора. Тогда при 80 % времени ожидания ввода-выво¬ 
да за каждую минуту своего нахождения в памяти задача использует только 12 с 
времени процессора, даже если нет никаких других параллельных заданий, также 
желающих занять процессор. Остальные 48 с процесс проводит в ожидании вво¬ 
да-вывода. Таким образом, задача должна находиться в памяти по крайней мере 
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20 мин для того, чтобы процессор сделал работу, требующую на самом деле всего 
4 мин, и это все при отсутствии конкуренции на право использования процессора. 

Что же происходит дальше? С 10:00 до 10:10 утра в памяти находится целиком 
первая задача и выполняется половина работы (2 мин работы процессора). Когда 
в 10:10 поступает второе задание, загрузка процессора увеличивается с 0,20 до 0,36 
вследствие более высокой степени многозадачности (см. рис. 4.3). Однако при 
циклическом планировании каждое задание получает для себя половину времени 
процессора, поэтому за каждую минуту нахождения в памяти выполняется часть 
задачи, требующая 0,18 мин работы процессора. Заметим, что добавление вто¬ 
рой задачи обходится первой задаче всего в 10 % ее производительности. Время 
использования процессора за минуту реального времени уменьшилось с 0,20 мин 
до 0,18 мин. 

В 10:15 утра поступает третье задание. В этот момент для первой задачи про¬ 
цессор отработал 2,9 мин, для второй — 0,9 мин. Степень многозадачности теперь 
равна 3, каждое задание получает для себя 0,16 мин работы процессора за минуту 
реального времени, как показано на рис. 4.4, б. Тогда с 10:15 до 10:20 утра для каж¬ 
дого из трех заданий процессор работает по 0,8 мин. В 10:20 утра поступает чет¬ 
вертая задача. На рис. 4.4, в представлена полная последовательность событий. 


Время Количество минут 
Задача поступления работы процесса 
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Рис. 4.4. Время поступления и рабочие требования четырех задач (а); загруженность 
процессора для количества задач от 1 до 4 при 80 % ожидания ввода-вывода (б); 
последовательность событий при поступлении и завершении обработки задач (в). 
Числа над горизонтальными линиями показывают время процессора в минутах, 
получаемое каждой задачей в каждом интервале времени 
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Настройка адресов и защита 

Многозадачность вносит две существенные проблемы, требующие решения, — это 
настройка адресов для перемещения программы в памяти и защита. Посмотрите 
на рис. 4.2. Из рисунка становится ясно, что разные задачи будут запущены по раз¬ 
личным адресам. Когда программа компонуется (то есть в едином адресном про¬ 
странстве объединяются основной модуль, написанные пользователем процедуры 
и библиотечные процедуры), компоновщик должен знать, с какого адреса будет 
начинаться программа в памяти. 

Например, предположим, что первая команда представляет собой вызов про¬ 
цедуры с абсолютным адресом 100 внутри двоичного файла, создаваемого компо¬ 
новщиком. Если эта программа загружается в раздел 1 (по адресу 100 К), команда 
обратится к абсолютному адресу 100, который находится внутри операционной 
системы. А нужно вызвать процедуру по адресу 100 К + 100. Если же программа 
загружается во второй раздел, команду нужно переадресовать на 200 К + 100 и т. д. 
Эта проблема известна как проблема перемещения программ в памяти или на¬ 
стройки адресов. 

Одним из возможных решений является модификация команд во время за¬ 
грузки программы в память. В программе, загружаемой в первый раздел, к каждо¬ 
му адресу прибавляется 100 К, в программе, которая загружается во второй раз¬ 
дел, к адресам добавляется 200 К и т. д. Чтобы выполнить подобную настройку 
адресов во время загрузки, компоновщик должен включить в двоичную програм¬ 
му список или битовый массив с информацией о том, какие слова в программе яв¬ 
ляются адресами (и их нужно перераспределить), а какие — кодами машинных 
команд, постоянными или другими частями программы, которые не нужно изме¬ 
нять. Таким образом работает операционная система 05/МРТ. 

Настройка адресов во время загрузки не решает проблемы защиты. Вредонос¬ 
ные программы всегда могут создать новую команду и перескочить на нее. По¬ 
скольку при такой системе программы предпочитают использовать абсолютную 
адресацию памяти, а не адреса относительно какого-либо регистра, не существует 
способа, который позволил бы запретить программе построение команды, обра¬ 
щающейся к любому слову в памяти для его чтения или записи. В многопользова¬ 
тельских системах крайне нежелательно разрешать процессам чтение или запись 
в область памяти, принадлежащую другим пользователям. 

Для защиты компьютера 360 компания ІВМ приняла следующее решение: она 
разделила память на блоки по 2 Кбайт и назначила каждому блоку 4-битовый за¬ 
щитный код. Регистр Р5\Ѵ (Рго§гаш Зіаіиз \Ѵог(1 — слово состояния программы) 
содержал 4-битовый ключ. Аппаратура ІВМ 360 перехватывала все попытки ра¬ 
ботающих процессов обратиться к любой части памяти, чей защитный код отли¬ 
чался от содержимого регистра слова состояния программы. Так как только 
операционная система могла изменять коды защиты и ключи, предотвращалось 
вмешательство пользовательских процессов в дела друг друга и в работу операци¬ 
онной системы. 

Альтернативное решение сразу обеих проблем (защиты и перераспределения) 
заключается в оснащении машины двумя специальными аппаратными регистра¬ 
ми, называемыми базовым и предельным регистрами. При планировании процес- 
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са в базовый регистр загружается адрес начала раздела памяти, а в предельный 
регистр помещается длина раздела. К каждому автоматически формируемому ад¬ 
ресу перед его передачей в память прибавляется содержимое базового регистра. 
Таким образом, если базовый регистр содержит величину 100 К, команда САН 100 
будет превращена в команду САН 100К+100 без изменения самой команды. Кроме 
того, адреса проверяются по отношению к предельному регистру для гарантии, что 
они не используются для адресации памяти вне текущего раздела. Базовый и пре¬ 
дельный регистры защищаются аппаратно, чтобы не допустить их изменений 
пользовательскими программами. 

Неудобство этой схемы заключается в том, что требуется выполнять операции 
сложения и сравнения при каждом обращении к памяти. Операция сравнения мо¬ 
жет быть выполнена быстро, но сложение — это медленная операция, что обуслов¬ 
лено временем распространения сигнала переноса, за исключением тех случаев, 
когда употребляется специальная микросхема сложения. 

Такая схема использовалась на первом суперкомпьютере в мире СОС 6600. 
В центральном процессоре Іпіеі 8088 для первых ІВМ РС применялась упрощен¬ 
ная версия этой модели: были базовые регистры, но отсутствовали предельные. 
Сейчас такую схему можно встретить лишь в немногих компьютерах. 


Подкачка 

Организация памяти в виде фиксированных разделов проста и эффективна для 
работы с пакетными системами. Каждое задание после того, как доходит до на¬ 
чала очереди, загружается в раздел памяти и остается там до своего завершения. 
До тех пор пока в памяти может храниться достаточное количество задач для 
обеспечения постоянной занятости центрального процессора, нет причин что-либо 
усложнять. 

Но совершенно другая ситуация сложилась с системами разделения време¬ 
ни или персональными компьютерами, ориентированными на работу с графикой. 
Оперативной памяти иногда оказывается недостаточно для того, чтобы вместить 
все текущие активные процессы, и тогда избыток процессов приходится хранить 
на диске, а для обработки динамически переносить их в память. 

Существуют два основных подхода к управлению памятью, зависящие (отчас¬ 
ти) от доступного аппаратного обеспечения. Самая простая стратегия, называемая 
свопингом (5\ѵарріп§) или обычной подкачкой, заключается в том, что каждый 
процесс полностью переносится в память, работает некоторое время и затем це¬ 
ликом возвращается на диск. Другая стратегия, носящая название виртуальной па¬ 
мяти, позволяет программам работать даже тогда, когда они только частично на¬ 
ходятся в оперативной памяти. Ниже мы изучим свопинг, а вторую стратегию 
рассмотрим в разделе «Виртуальная память» данной главы. 

Работа системы свопинга проиллюстрирована на рис. 4.5. На начальной стадии 
в памяти находится только процесс А. Затем создаются или загружаются с диска 
процессы В и С. На рис. 4.5, г процесс Л выгружается на диск. Затем появляет¬ 
ся процесс Д а процесс В завершается. Наконец, процесс А снова возвращается 
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в память. Так как теперь процесс А имеет другое размещение в памяти, его адреса 
должны быть перенастроены или программно во время загрузки в память, или 
(более заманчивый вариант) аппаратно во время выполнения программы. 

Время-► 



д е ж 

Рис. 4.5. Распределение памяти изменяется по мере того, как процессы поступают 
в память и покидают ее. Заштрихованы неиспользуемые области памяти 

Основная разница между фиксированными разделами на рис. 4.2 и непосто¬ 
янными разделами на рис. 4.5 заключается в том, что во втором случае количе¬ 
ство, размещение и размер разделов изменяются динамически по мере поступ¬ 
ления и завершения процессов, тогда как в первом варианте они фиксированы. 
Гибкость схемы, в которой нет ограничений, связанных с определенным коли¬ 
чеством разделов, и каждый из разделов может быть очень большим или совсем 
маленьким, улучшает использование памяти, но, кроме того, усложняет опера¬ 
ции размещения процессов и освобождения памяти, а также отслеживание проис¬ 
ходящих изменений. 
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Когда в результате подкачки процессов с диска в памяти появляется множе¬ 
ство неиспользованных фрагментов, их можно объединить в один большой учас¬ 
ток, передвинув все процессы в сторону младших адресов настолько, насколько 
это возможно. Такая операция называется уплотнением или сжатием памяти. 
Обычно ее не выполняют, потому что на нее уходит много времени работы про¬ 
цессора. Например, на машине с 256 Мбайт оперативной памяти, которая может 
копировать 4 байта за 40 нс, уплотнение всей памяти займет около 2,7 с. 

Еще один момент, на который стоит обратить внимание: сколько памяти долж¬ 
но быть предоставлено процессу, когда он создается или скачивается с диска? Если 
процесс имеет фиксированный никогда не изменяющийся размер, размещение 
происходит просто: операционная система предоставляет точно необходимое ко¬ 
личество памяти, ни больше, ни меньше, чем нужно. 

Однако если область данных процесса может расти, например, в результате 
динамического распределения памяти из кучи 1 , как происходит во многих языках 
программирования, проблема предоставления памяти возникает каждый раз, когда 
процесс пытается увеличиться. Когда участок неиспользованной памяти располо¬ 
жен рядом с процессом, его можно отдать в пользу процесса, таким образом, позво¬ 
лив процессу вырасти на размер этого участка. Если же процесс соседствует с дру¬ 
гим процессом, для его увеличения нужно или переместить достаточно большой 
свободный участок памяти, или перекачать на диск один или больше процессов, 
чтобы создать незанятый фрагмент достаточного размера. Если процесс не может 
расти в памяти, а область на диске, предоставленная для подкачки, переполнена, 
процесс будет вынужден ждать освобождения памяти или же будет уничтожен. 

Если предположить, что большинство процессов будут увеличиваться во вре¬ 
мя работы, вероятно, сразу стоит предоставлять им немного больше памяти, чем 
требуется, а всякий раз, когда процесс скачивается на диск или перемещается 
в памяти, обрабатывать служебные данные, связанные с перемещением или подкач¬ 
кой процессов, больше не умещающихся в предоставленной им памяти. Но когда 
процесс выгружается на диск, должна скачиваться только действительно исполь¬ 
зуемая часть памяти, так как очень расточительно также перемещать и дополни¬ 
тельную память. На рис. 4.6, а можно увидеть конфигурацию памяти с предостав¬ 
лением пространства для роста двух процессов. 

Если процесс может иметь два увеличивающихся сегмента, например сегмент 
данных, используемый как куча для динамически назначаемых и освобождаемых 
переменных, и сегмент стека для обычных локальных переменных и возвращае¬ 
мых адресов, предлагается альтернативная схема распределения памяти, показан¬ 
ная на рис. 4.6, б. Здесь мы видим, что у каждого процесса вверху предоставлен¬ 
ной ему области памяти находится стек, который расширяется вниз, и сегмент 
данных, расположенный отдельно от текста программы, который увеличивается 
вверх. Область памяти между ними разрешено использовать для любого сегмента. 
Если ее становится недостаточно, то процесс нужно или перенести на другое, боль¬ 
шее свободное место, или выгрузить на диск до появления свободного простран¬ 
ства необходимого размера, или уничтожить. 


1 Кучей (Ьеар) называется область памяти, выделяемая программе для динамически размещаемых 
структур данных. — Примеч. перев. 
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Рис. 4.6. Предоставление пространства для роста области данных (а); 
предоставление пространства для роста стека и области данных (б) 

Управление памятью с помощью 
битовых массивов 

Если память выделяется динамически, этим процессом должна управлять опера¬ 
ционная система. Существует два способа учета использования памяти; бито¬ 
вые массивы, иногда называемые битовыми картами, и списки свободных участ¬ 
ков. В этом и следующем разделах мы по очереди рассмотрим оба метода. 

При работе с битовым массивом память разделяется на единичные блоки раз¬ 
мещения размером от нескольких слов до нескольких килобайт. В битовой карте 
каждому свободному блоку соответствует один бит, равный нулю, а каждому за¬ 
нятому блоку — бит, установленный в 1 (или наоборот). На рис. 4.7 показана часть 
памяти и соответствующий ей битовый массив. Черточками отмечены единичные 
блоки памяти. Заштрихованные области (0 в битовой карте) свободны. 

Размер единичного блока представляет собой важный вопрос стадии разработ¬ 
ки системы. Чем меньше единичный блок, тем больше потребуется битовый мас¬ 
сив. Однако даже при маленьком единичном блоке, равном четырем байтам, для 
32 битов памяти потребуется 1 бит в карте. Тогда память размером в 32 п будет ис¬ 
пользовать п битов в карте, таким образом, битовая карта займет всего лишь 1/33 
часть памяти. Если выбираются большие единичные блоки, битовая карта стано¬ 
вится меньше, но при этом может теряться существенная часть памяти в послед¬ 
нем блоке каждого процесса (если размер процесса не кратен размеру единичного 
блока). 

Битовый массив предоставляет простой способ отслеживания слов в памяти 
фиксированного объема, потому что размер битовой карты зависит только от 
оазмеров памяти и единичного блока. Основная проблема, возникающая при 
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этой схеме, заключается в том, что при решении переместить А-блочный процесс 
в память модуль управления памяти должен найти в битовой карте серию из 
к следующих друг за другом нулевых битов. Поиск серии заданной длины в бито¬ 
вой карте является медленной операцией (так как искомая последовательность 
битов может пересекать границы слов в битовом массиве). В этом состоит аргу¬ 
мент против битовых карт. 



Свободный 

фрагмент 

Рис. 4.7. Часть памяти с пятью процессами и тремя свободными областями (а); 
соответствующая битовая карта (б); та же информация в виде списка (в) 

Управление памятью с помощью связных списков 

Другой способ отслеживания состояния памяти предоставляет поддержка связных 
списков занятых и свободных фрагментов памяти, где сегментом является или 
процесс, или участок между двумя процессами. Память, показанная на рис. 4.7, а , 
представлена в виде связного списка сегментов на рис. 4.7, е. Каждая запись в спис¬ 
ке указывает, является ли область памяти свободной (Н, от Ьоіе — дыра) или за¬ 
нятой процессом (Р, ргосезз); адрес, с которого начинается эта область; ее длину; 
содержит указатель на следующую запись. 

В нашем примере список отсортирован по адресам. Такая сортировка имеет 
следующее преимущество: когда процесс завершается или скачивается на диск, 
изменение списка представляет собой несложную операцию. Закончившийся про¬ 
цесс обычно имеет двух соседей (кроме тех случаев, когда он находится на самом 
верху или на дне памяти). Соседями могут быть процессы или свободные фрагмен¬ 
ты, что приводит к четырем комбинациям, показанным на рис. 4.8. На рис. 4.8, а 
корректировка списка требует замены Р на Н. На рис. 4.8, б, в две записи соединя¬ 
ются в одну, а список становится на запись короче. На рис. 4.8, г объединяются 
три записи, а из списка удаляются два пункта. Так как ячейка таблицы процессов 
для завершившегося процесса обычно будет непосредственно указывать на запись 
в списке для этого процесса, возможно, удобнее иметь список с двумя связями, чем 
с одной (последний показан на рис. 4.7, в). Такая структура упрощает поиск пре¬ 
дыдущей записи и оценку возможности соединения. 
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До завершения X После завершения X 

Становиться 


Становиться 


Становиться 


Становиться 

Рис. 4.8. Четыре комбинации соседей для завершения процесса X 

Если процессы и свободные участки хранятся в списке, отсортированном по 
адресам, существует несколько алгоритмов для предоставления памяти процессу, 
создаваемому заново (или для существующих процессов, скачиваемых с диска). 
Допустим, менеджер памяти знает, сколько памяти нужно предоставить. Простей¬ 
ший алгоритм представляет собой выбор первого подходящего участка. Менед¬ 
жер памяти просматривает список областей до тех пор, пока не находит достаточ¬ 
но большой свободный участок. Затем этот участок делится на две части: одна 
отдается процессу, а другая остается неиспользуемой. Так происходит всегда, 
кроме статистически нереального случая точного соответствия свободного участ¬ 
ка и процесса. Это быстрый алгоритм, потому что поиск уменьшен настолько, на¬ 
сколько возможно. 

Алгоритм «следующий подходящий участок» действует с минимальными от¬ 
личиями от правила «первый подходящий». Он работает так же, как и первый ал¬ 
горитм, но всякий раз, когда находит соответствующий свободный фрагмент, он 
запоминает его адрес. И когда алгоритм в следующий раз вызывается для поиска, 
он стартует с того самого места, где остановился в прошлый раз вместо того, чтобы 
каждый раз начинать поиск с начала списка, как это делает алгоритм «первый под¬ 
ходящий». Моделирование работы алгоритма, произведенное Бэйсом, показало, 
что производительность схемы «следующий подходящий» немного хуже, чем 
«первый подходящий» [21]. 

Другой хорошо известный алгоритм называется «самый подходящий учас¬ 
ток». Он выполняет поиск по всему списку и выбирает наименьший по размеру 
подходящий свободный фрагмент. Вместо того чтобы делить большую незанятую 
область, которая может понадобиться позже, этот алгоритм пытается найти учас¬ 
ток, близко подходящий к действительно необходимым размерам. 

Чтобы привести пример работы алгоритмов «первый подходящий» и «самый 
подходящий», снова обратимся к рис. 4.7. Если необходим блок размером 2, пра¬ 
вило «первый подходящий» предоставит область по адресу 5, а схема «самый под¬ 
ходящий» разместит процесс в свободном фрагменте по адресу 18. 

Алгоритм «самый подходящий» медленнее «первого подходящего», потому что 
каждый раз он должен производить поиск во всем списке. Но, что немного удиви¬ 
тельно, он выдает еще более плохие результаты, чем «первый подходящий» или 
«следующий подходящий», поскольку стремится заполнить память очень малень¬ 
кими, бесполезными свободными областями, то есть фрагментирует память. Алго¬ 
ритм «первый подходящий» в среднем создает большие свободные участки. 
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Пытаясь решить проблему разделения памяти на практически точно совпада¬ 
ющие с процессом области и маленькие свободные фрагменты, можно задуматься 
об алгоритме «самый неподходящий участок». Он всегда выбирает самый боль¬ 
шой свободный участок, от которого после разделения остается область достаточ¬ 
ного размера и ее можно использовать в дальнейшем. Однако моделирование по¬ 
казало, что это также не очень хорошая идея. 

Все четыре алгоритма можно ускорить, если поддерживать отдельные списки 
для процессов и свободных областей. Тогда поиск будет производиться только 
среди незанятых фрагментов. Неизбежная цена, которую нужно заплатить за уве¬ 
личение скорости при размещении процесса в памяти, заключается в дополнитель¬ 
ной сложности и замедлении при освобождении областей памяти, так как ставший 
свободным фрагмент необходимо удалить из списка процессов и вставить в спи¬ 
сок незанятых участков. 

Если для процессов и свободных фрагментов поддерживаются отдельные спис¬ 
ки, то последний можно отсортировать по размеру, тогда алгоритм «самый подхо¬ 
дящий» будет работать быстрее. Когда он выполняет поиск в списке свободных 
фрагментов от самого маленького к самому большому, то, как только находит 
подходящую незанятую область, алгоритм уже знает, что она — наименьшая из тех, 
в которых может поместиться задание, то есть наилучшая. В отличие от схемы 
с одним списком, дальнейший поиск не требуется. Таким образом, если список 
свободных фрагментов отсортирован по размеру, схемы «первый подходящий» 
и «самый подходящий» одинаково быстры, а алгоритм «следующий подходящий» 
не имеет смысла. 

При поддержке отдельных списков для процессов и свободных фрагментов воз¬ 
можна небольшая оптимизация. Вместо создания отдельного набора структур дан¬ 
ных для списка свободных участков, как это сделано на рис. 4.7, в, можно исполь¬ 
зовать сами свободные области. Первое слово каждого незанятого фрагмента 
может содержать размер фрагмента, а второе слово может указывать на следую¬ 
щую запись. Узлы списка на рис. 4.7, е, для которых требовались три слова и один 
бит (Р/Н), больше не нужны. 

Еще один алгоритм распределения называется «быстрый подходящий», он 
поддерживает отдельные списки для некоторых из наиболее часто запрашиваемых 
размеров. Например, могла бы существовать таблица с п записями, в которой пер¬ 
вая запись указывает на начало списка свободных фрагментов размером 4 Кбайт, 
вторая запись является указателем на список незанятых областей размером 
8 Кбайт, третья — 12 Кбайт и т. д. Свободный фрагмент размером, скажем, 21 байт, 
мог бы располагаться или в списке областей 20 Кбайт или в специальном списке 
участков дополнительных размеров. При использовании правила «быстрый под¬ 
ходящий» поиск фрагмента требуемого размера происходит чрезвычайно быстро. 
Но этот алгоритм имеет тот же самый недостаток, что и все схемы, которые сорти¬ 
руют свободные области по размеру, а именно: если процесс завершается или вы¬ 
гружается на диск, поиск его соседей с целью узнать, возможно ли их соединение, 
является дорогой операцией. А если не производить слияния областей, память 
очень скоро окажется разбитой на огромное число маленьких свободных фрагмен¬ 
тов, в которые не поместится ни один процесс. 
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Виртуальная память 

Уже достаточно давно люди впервые столкнулись с проблемой размещения про¬ 
грамм, оказавшихся слишком большими и поэтому не помещавшихся в доступной 
физической памяти. Обычно принималось решение о разделении программы на 
части, называемые оверлеями (оѵегіауз). Оверлей 0 обычно запускался первым. 
После окончания своего выполнения он вызывал следующий оверлей. Некоторые 
оверлейные системы были очень сложными, позволяющими одновременно нахо¬ 
диться в памяти нескольким оверлеям. Оверлеи хранились на диске и по мере не¬ 
обходимости динамически перемещались между памятью и диском средствами 
операционной системы. 

Несмотря на то что фактическая работа по загрузке оверлеев с диска и выгруз¬ 
ке на диск выполнялась системой, делить программы на части должен был про¬ 
граммист. Разбиение больших программ на маленькие модули поглощало много 
времени и было не слишком интересным занятием. Однако такая ситуация про¬ 
должалась недолго, так как вскоре кто-то придумал способ поручить всю эту рабо¬ 
ту компьютеру. 

Разработанный метод известен как виртуальная память [122]. Основная идея 
виртуальной памяти заключается в том, что объединенный размер программы, дан¬ 
ных и стека может превысить количество доступной физической памяти. Опера¬ 
ционная система хранит части программы, использующиеся в настоящий момент, 
в оперативной памяти, остальные — на диске. Например, программа размером 
16 Мбайт сможет работать на машине с 4 Мбайт памяти, если тщательно проду¬ 
мать, какие 4 Мбайт должны храниться в памяти в каждый момент времени. При 
этом части программы, находящиеся на диске и в памяти, будут меняться местами 
по мере необходимости. 

Виртуальная память может также работать в многозадачной системе при одно¬ 
временно находящихся в памяти частях многих программ. Когда программа ждет 
перемещения в память очередной ее части, она находится в состоянии ожидания 
ввода-вывода и не может работать, поэтому центральный процессор может быть 
отдан другому процессу тем же самым способом, как в любой другой многозадач¬ 
ной системе. 

Страничная организация памяти 

Большинство систем виртуальной памяти используют технику, называемую стра¬ 
ничной организацией памяти (ра§іп§), которую мы сейчас опишем. На любом ком¬ 
пьютере существует множество адресов в памяти, к которым может обратиться 
программа. Когда программа использует следующую инструкцию 

МОѴ КЕС.1000 

она делает это для того, чтобы скопировать содержимое памяти по адресу 1000 
в регистр КЕ6 (или наоборот, в зависимости от компьютера). Адреса могут форми¬ 
роваться с использованием индексации, базовых регистров, сегментных регистров 
и другими путями. 
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Центральный 

процессор 


Центральный процессор передает 



Диспетчер памяти посылает 
физический адрес в память 


Рис. 4.9. Расположение и функции диспетчера памяти (ММІІ). Здесь диспетчер памяти 
показан как часть микросхемы процессора, потому что в наши дни это обычно так и есть. 
Но логически он мог бы быть отдельной микросхемой, и так было некоторое время назад 


Эти программно формируемые адреса, называемые виртуальными адресами, 
формируют виртуальное адресное пространство. На компьютерах без виртуальной 
памяти виртуальные адреса подаются непосредственно на шину памяти и вызыва¬ 
ют для чтения или записи слово в физической памяти с тем же самым адресом. 
Когда используется виртуальная память, виртуальные адреса не передаются на¬ 
прямую шиной памяти. Вместо этого они передаются диспетчеру памяти (ММІІ — 
Мешогу Мапа§ешепС ИпіС), который отображает виртуальные адреса на физичес¬ 
кие адреса памяти, как продемонстрировано на рис. 4.9. 

Очень простой пример того, как работает отображение, приведен на рис. 4,10. 
Мы рассматриваем компьютер, который может формировать 16-разрядные адре¬ 
са, от 0 до 64 К. Это виртуальные адреса. Однако у этого компьютера только 
32 Кбайт физической памяти, поэтому, хотя программы размером 64 Кбайт могут 
быть написаны, они не могут целиком быть загружены в память и запущены. Пол¬ 
ная копия образа памяти программы размером до 64 Кбайт должна присутство¬ 
вать на диске, но в таком виде, чтобы ее можно было по мере надобности перено¬ 
сить в память по частям. 

Пространство виртуальных адресов разделено на единицы, называемые стра¬ 
ницами. Соответствующие единицы в физической памяти называются странич¬ 
ными блоками (ра§е Дате). Страницы и их блоки имеют всегда одинаковый раз¬ 
мер. В этом примере они равны 4 Кбайт, но в реальных системах использовались 
размеры страниц от 512 байт до 64 Кбайт. Имея 64 Кбайт виртуального адресного 
пространства и 32 Кбайт физической памяти, мы получаем 16 виртуальных стра¬ 
ниц и 8 страничных блоков. Передача данных между ОЗУ и диском всегда проис¬ 
ходит в страницах. 

Когда программа пытается получить доступ к адресу 0, например, используя 
команду 

МОѴ КЕС.О 

виртуальный адрес 0 передается диспетчеру памяти (ММИ). Диспетчер памяти 
видит, что этот виртуальный адрес попадает на страницу 0 (от 0 до 4095), которая 
отображается страничным блоком 2 (от 8192 до 12287). Диспетчер переводит 
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виртуальный адрес 0 в физический адрес 8192 и выставляет последний на шину. 
Память ничего не знает о диспетчере памяти и видит просто запрос на чтение или 
запись слова по адресу 8192, который и выполняет. Таким образом, диспетчер па¬ 
мяти эффективно отображает все виртуальные адреса между 0 и 4095 на физичес¬ 
кие адреса от 8192 до 12287. 

Виртуальное 
адресное пространство 

60 —64К 
56—60К 
52 — 56К 
48 —52К 
44—48К 
40 —44К 
36 — 40К 
32 —36К 
28 —32К 
24 —28К 
20 —24К 
16 —20К 
12 —16К 
8—12К 
4—8К 
0 —4К 

Страничный 

блок 

Рис. 4.10. Связь между виртуальными и физическими адресами, 
получаемая с помощью таблицы страниц 

Точно так же инструкция 
МОѴ КЕ6.8192 

преобразуется в команду 
МОѴ КЕО. 24576 

поскольку виртуальный адрес 8192 находится на виртуальной странице 2, а эта 
страница отображается на физический страничный блок 6 (физические адреса от 
24576 до 28671). В качестве третьего примера рассмотрим виртуальный адрес 20500, 
который адресует 20-й байт от начала виртуальной страницы 5 (виртуальные адре¬ 
са от 20480 до 24575) и отображается на физический адрес 12288 + 20 = 12308. 

Сама по себе возможность отображения 16 виртуальных страниц на любой из 
восьми страничных блоков с помощью установки соответствующей карты в дис¬ 
петчере памяти не решает проблемы, заключающейся в том, что размер виртуаль¬ 
ного адресного пространства больше физической памяти. Так как у нас есть толь¬ 
ко восемь физических страничных блоков, только восемь виртуальных страниц на 





Виртуальная память 


235 


рис. 4.10 воспроизводятся в физической памяти. Другие страницы, обозначенные 
на рисунке крестиками, не отображаются. В фактическом аппаратном обеспече¬ 
нии страницы, физически присутствующие в памяти, отслеживаются с помощью 

бита присутствия/отсутствия. 

Что происходит, если программа пытается воспользоваться неотображаемой 
страницей, например, с помощью инструкции 

МОѴ КЕС.32780 

которая обращается к байту 12 на виртуальной странице 8 (начинающейся с адре¬ 
са 32768)? Диспетчер памяти замечает, что страница не отображается (обозначе¬ 
на крестиком на рисунке), и инициирует прерывание центрального процессора, 
передающее управление операционной системе. Такое прерывание называется 
ошибкой из-за отсутствия страницы или страничным прерыванием (ра§е Іаик). 
Операционная система выбирает малоиспользуемый страничный блок и записы¬ 
вает его содержимое на диск. Затем она считывает с диска страницу, на которую 
произошла ссылка, в только что освободившийся блок, изменяет карту отображе¬ 
ния и запускает заново прерванную команду. 

Например, если операционная система решает удалить из оперативной памяти 
страничный блок 1, она загружает виртуальную страницу 8 по физическому адре¬ 
су 4 К и производит два изменения в карте диспетчера памяти. Во-первых, отме¬ 
чается содержимое виртуальной страницы 1 как неотображаемое для того, чтобы 
перехватывать в будущем любые попытки обращения к виртуальным адресам меж¬ 
ду 4 К и 8 К. Затем заменяется крест в записи для виртуальной страницы 8 на но¬ 
мер 1, так что когда прерванная команда будет выполняться заново, она отобразит 
виртуальный адрес 32780 на физический адрес 4108. 

Теперь рассмотрим диспетчер памяти изнутри, чтобы увидеть, как он работает, 
и понять, почему мы выбрали размер страницы, являющийся степенью числа 2. 
На рис. 4.11 представлен пример виртуального адреса 8196 (0010000000000100 
в двоичном виде), который отображается с использованием карты диспетчера 
памяти на рис. 4.10. Входящий 16-разрядный виртуальный адрес разделяется на 
4-разрядный номер страницы и 12 битов смещения. При 4 битах под номер стра¬ 
ницы в нашей системе может существовать 16 страниц, а с 12 битами смещения 
мы можем адресоваться ко всем 4096 байтам внутри страницы. 

Номер страницы используется в качестве индекса в таблице страниц, выдаю¬ 
щей номер страничного блока, соответствующего виртуальной странице. Если бит 
Присутствия/отсутствия равен 0, управление переходит к операционной систе¬ 
ме. Если этот бит равен 1, то номер страничного блока, найденный в таблице стра¬ 
ниц, записывается в три старших бита выходного регистра, а 12 битов смещения 
копируются без изменения из входящего виртуального адреса. Все вместе они со¬ 
ставляют 15-разрядный физический адрес. Затем выходной регистр помещается 
на шину памяти как адрес физической памяти. 

Таблицы страниц 

В простейшем случае отображение виртуальных адресов на физические происхо¬ 
дит так, как мы только что описали. Виртуальный адрес делится на номер виртуаль¬ 
ной страницы (старшие биты) и сдвиг (младшие биты). Например, при 16-разряд- 
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ных адресах и размере страницы 4 Кбайт старшие 4 бита могут указывать одну из 
16 виртуальных страниц, а нижние 12 бит могут определять байт смещения (от О 
до 4095) внутри выбранной страницы. Однако разбиение страницы на 3,5 или какое- 
нибудь другое число битов также возможно. Разные части подразумевают различ¬ 
ные размеры страниц. 
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Физическай адрес 
на выходе (24580) 


Виртуальный адрес 
на входе (8196) 


Рис. 4.11 . Внутренняя операция диспетчера памяти в системе 
с шестнадцатью страницами размером 4 Кбайт 

Номер виртуальной страницы используется как индекс в таблице страниц для 
поиска записи этой страницы. По записи в таблице страниц находится номер фи¬ 
зического блока страницы (если это имеет место). Данный номер присоединяется 
к старшим разрядам числа смещения, замещая номер виртуальной страницы и тем 
самым формируя физический адрес, который может быть послан в память. 

Назначение таблицы страниц заключается в отображении виртуальных стра¬ 
ниц на страничные блоки. Говоря математически, таблица страниц — это функция, 
имеющая в качестве аргумента номер виртуальной страницы и получающая в ре¬ 
зультате номер физического блока. Используя результат действия этой функции, 
поле виртуальной страницы в виртуальном адресе может быть заменено полем 
страничного блока, таким образом, формируется физический адрес. 
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Несмотря на столь простое описание, нам придется столкнуться с двумя важ¬ 
ными проблемами: 

1. Таблица страниц может быть слишком большой. 

2. Отображение должно быть быстрым. 

Первый пункт следует из того факта, что современные компьютеры исполь¬ 
зуют по крайней мере 32-разрядные виртуальные адреса. При размере страницы, 
скажем, 4 Кбайт, 32-разрядное адресное пространство будет состоять из одного 
миллиона страниц, а 64-разрядное адресное пространство будет включать в себя 
намного больше страниц, чем то количество, с которым вы захотите иметь дело. 
При одном миллионе страниц в виртуальном адресном пространстве таблица 
страниц должна состоять из одного миллиона записей. И помните, что каждый 
процесс нуждается в своей собственной таблице страниц (потому что у него есть 
свое собственное виртуальное адресное пространство). 

Второй пункт — это вывод из того факта, что преобразование виртуальных адре¬ 
сов в физические должно быть выполнено для каждого обращения к ячейке памя¬ 
ти. Типичная команда процессора включает в себя слово-команду и часто также 
операнд памяти. В результате необходимо сделать 1,2 или иногда больше обраще¬ 
ний к таблице страниц за команду. Если выполнение команды занимает, скажем, 
4 нс, то поиск в таблице страниц должен быть сделан меньше, чем за 1 нс, чтобы 
преобразование виртуальных адресов не стало главным узким местом системы. 

Потребность в огромном, но при этом быстром страничном отображении на¬ 
кладывает существенные ограничения на способы построения компьютеров. Хотя 
проблема наиболее серьезно встает для старших моделей семейства, она также 
появляется и для младших моделей, когда стоимость и соотношение цена/произ¬ 
водительность имеют критическое значение. В этом и следующих разделах мы рас¬ 
смотрим устройство таблицы страниц в деталях и покажем несколько аппаратных 
решений, которые использовались в реальных компьютерах. 

Простейшее конструкторское решение (по крайней мере, концептуально) за¬ 
ключается в поддержании таблицы страниц, состоящей из массива быстрых аппа¬ 
ратных регистров с одной записью для каждой виртуальной страницы, индексиро¬ 
ванного по номерам виртуальных страниц, как показано на рис. 4.11. Когда процесс 
запускается, операционная система загружает в регистры таблицу страниц процес¬ 
са, данные берутся из копии, хранящейся в оперативной памяти. Во время выпол¬ 
нения процесса таблице страниц больше не нужно обращаться к памяти. Преиму¬ 
щество этого метода заключается в его простоте и отсутствии необходимости 
обращений к памяти во время преобразования адресов. Недостатком является его 
потенциально высокая стоимость (если таблица страниц велика). Необходимость 
загрузки полной таблицы в регистры при каждом контекстном переключении 
наносит ущерб производительности. 

Другая крайность заключается в том, что таблица страниц целиком располагает¬ 
ся в оперативной памяти. Тогда все необходимое оборудование состоит из одного- 
единственного регистра, указывающего на начало таблицы страниц. Такая схема 
позволяет изменять карту памяти при контекстном переключении путем переза¬ 
грузки только одного регистра. Конечно, она имеет свой недостаток: во время вы¬ 
полнения каждой инструкции программы требуется одно или несколько обраще- 
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ний к памяти для чтения записей таблицы страниц. По этой причине данный ме¬ 
тод редко используется в своем чистом виде, но ниже мы изучим несколько его 
разновидностей, имеющих намного более высокую производительность. 

Многоуровневые таблицы страниц 

Чтобы обойти проблему необходимости постоянного хранения в памяти огром¬ 
ных таблиц страниц, многие компьютеры используют многоуровневую таблицу 
страниц. Простой пример представлен на рис. 4.12. На рис. 4.12, а изображен 
32-разрядный виртуальный адрес, который разделен на 10-разрядное поле РТ1, 
10-разрядное поле РТ2 и 12-разрядное поле 0//зеі (смещение). Так как под сме¬ 
щение отведено 12 бит, страницы имеют размер 4 Кбайт, и их всего 2 2(| . 


Таблица страниц 
второго уровня 



Таблица страниц 
для старших 
4 Мбайт памяти 


К страницам 


б 

Рис. 4.12. 32-разрядные адреса с полями двух таблиц страниц (а); 
двухуровневая таблица страниц (б) 
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Секрет метода многоуровневой таблицы страниц заключается в том, чтобы избе¬ 
гать постоянного содержания в памяти всех таблиц страниц. В частности, те части, 
которые не нужны в данный момент, не должны храниться в памяти. Предположим, 
например, что процессу нужно 12 Мбайт, младшие 4 Мбайт памяти для текста про¬ 
граммы, следующие 4 Мбайт для данных и старшие 4 Мбайт для стека. Между вер¬ 
хом данных и низом стека образуется гигантский свободный участок, который не 
используется. 

На рис. 4.12, б мы видим, как в данном примере работает двухуровневая табли¬ 
ца страниц. Слева находится таблица страниц верхнего уровня с 1024 записями, 
соответствующими 10-разрядному полю РТ 1. Когда виртуальный адрес предстает 
перед диспетчером памяти, он сначала выделяет поле РТ 1 и использует его зна¬ 
чение как индекс таблицы верхнего уровня. Каждая из этих 1024 записей пред¬ 
ставляет 4 М, потому что целое 4-гигабайтное (то есть 32-разрядное) виртуальное 
адресное пространство было нарезано на куски по 1024 байта. 

Запись, место которой определяется по индексу в таблице страниц верхнего 
уровня, выдает адрес или номер страничного блока таблицы страниц второго уров¬ 
ня. Запись 0 в таблице страниц первого уровня указывает на таблицу страниц для 
текста программы, запись 1 указывает на таблицу страниц для данных, запись 1023 
указывает на таблицу страниц для стека. Другие (заштрихованные) записи не ис¬ 
пользуются. Поле РТ2 теперь используется как индекс в выбранной таблице вто¬ 
рого уровня для поиска номера страничного блока самой страницы. 

В качестве примера рассмотрим 32-разрядный адрес 0x00403004 (4 206 596 
в десятичном виде), который соответствует байту 12 292 в данных. У этого вирту¬ 
ального адреса РТ\=1, РТ2=2 и 0//зеС=і. Диспетчер памяти сначала использует 
поле РТ1, чтобы по индексу в таблице страниц верхнего уровня получить запись 1, 
которая соответствует адресам от 4 до 8 М. Затем он воспользуется полем РТ2, 
чтобы по индексу из только что найденной таблицы второго уровня извлечь за¬ 
пись 3, которая соответствует адресам от 12 288 до 16 383 внутри своего участка 
размером 4 М (то есть абсолютным адресам от 4 206 592 до 4 210 687). Эта запись 
содержит номер физического блока страницы, содержащей виртуальный адрес 
0x00403004. Если данная страница не находится в памяти, бит Присутствия/от¬ 
сутствия в записи таблицы страниц будет равен нулю, что приведет к страничному 
прерыванию. Если страница в памяти, то номер страничного блока, взятый из таб¬ 
лицы страниц второго уровня, присоединяется к смещению (4), создавая физичес¬ 
кий адрес. Этот адрес выставляется на шину и передается памяти. 

Следует отметить одну интересную деталь на рис. 4.12. Хотя адресное простран¬ 
ство содержит больше миллиона страниц, фактически нужны только четыре таб¬ 
лицы: таблица верхнего уровня и таблицы нижнего уровня для памяти от 0 до 4 М, 
от 4 до 8 М и для верхних 4 М. Битам Присутствия/отсутствия для 1021 записи 
таблицы страниц верхнего уровня присвоено значение 0, что вызовет страничное 
прерывание при любом обращении к ним. Если это происходит, то операционная 
система заметит, что процесс пытается обратиться к области памяти, не предпола¬ 
гающей ссылок на нее, н предпримет соответствующее действие, например пошлет 
ему сигнал или уничтожит его. В описанном выше примере мы выбрали круглые 
значения для различных величин и выбрали размер поля РТІ, равный размеру 
поля РТ2, но в реальной практике, конечно, возможны другие цифры. 
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Система двухуровневой таблицы на рис. 4.12 может быть расширена для трех, 
четырех и больше уровней. Дополнительные уровни дадут большую гибкость, но 
сомнительно, что следует усложнять систему больше, чем до трех уровней. 

Структура элемента таблицы страниц 

Теперь от структуры таблиц страниц в целом мы перейдем к деталям отдель¬ 
ного элемента записи таблицы. Точная структура элемента в значительной мере 
зависит от машины, но виды представленной информации примерно одни и те же. 
На рис. 4.13 мы привели образец записи в таблице страниц. Ее длина изменяется 
от компьютера к компьютеру, но 32 бита — это наиболее распространенный раз¬ 
мер. Наиболее важным полем является Номер страничного блока. Прежде всего, 
задачей отображения страниц является определение этой величины. За этим по¬ 
лем следует бит Присутствия/отсутствия. Если этот бит равен 1, запись имеет 
силу и может использоваться. Если он равен 0, виртуальная страница, которой 
соответствует эта запись, в данный момент отсутствует в памяти. Обращение к за¬ 
писи в таблице страниц, у которой этому биту присвоено нулевое значение, при¬ 
водит к страничному прерыванию. 

Блокирование 

кэша Изменение Присутствие/отсутствие 










Номер страничного блока 


\ \ 


Обращение Защита 

Рис. 4.13. Типичная запись в таблице страниц 

Биты Защиты говорят о том, какие разрешены виды доступа к этой странице. 
В простейшей форме это поле содержит один бит, равный 1 для чтения/записи и 
равный 0 только для чтения. Более сложные схемы имеют три бита, по одному для 
допуска каждой из операций чтения, записи и выполнения страницы. 

Биты Изменения и Обращения отслеживают использование страницы. Когда 
страница записывается, аппаратура автоматически устанавливает бит Изменение.. 
Этот бит учитывается, когда операционная система решает освободить странич¬ 
ный блок. Если страница в нем была изменена (то есть она «грязная»), то ее но¬ 
вая версия должна быть переписана на диск. Если она не была модифицирована 
(то есть страница «чистая»), ее можно просто удалить из памяти, так как все еще 
действительна копия на диске. Этот бит иногда называют грязным битом, так как 
он отражает состояние страницы. 

Бит Обращения устанавливается всякий раз, когда происходит обращение к 
странице для чтения или записи. Его значение помогает операционной системе 
при выборе страницы для удаления из памяти, когда случается ошибка из-за 
отсутствия страницы. Страницы, не использующиеся в данный момент, явля¬ 
ются лучшими кандидатами, чем находящиеся в работе. Этот бит играет важную 
роль в нескольких алгоритмах перемещения страниц, которые мы изучим позже 
в этой главе. 
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Наконец, последний бит позволяет запретить кэширование страницы. Это свой¬ 
ство важно для страниц, отображающихся не на память, а на регистры устройств. 
Если операционная система находится в цикле ожидания ответа от некоторого 
устройства ввода-вывода, которому была только что дана команда, существенно, 
чтобы аппаратура продолжала получать слово из устройства, а не использовало 
старую копию, находящуюся в кэш-памяти. При помощи этого бита кэширование 
можно отключить. Машины, имеющие отдельное пространство адресов ввода-вы¬ 
вода и не использующие отображения регистров ввода-вывода на память, не нуж¬ 
даются в этом бите. 

Заметим, что адрес места на диске, в котором хранится страница тогда, когда 
она не находится в памяти, не является частью таблицы страниц. Причина очень 
проста. Таблица страниц содержит только ту информацию, которая нужна аппара¬ 
туре для перевода виртуального адреса в физический. Информация, необходимая 
операционной системе для обработки страничных прерываний, хранится в про¬ 
граммных таблицах внутри операционной системы. Аппаратуре она не нужна. 

Буферы быстрого преобразования адреса (ТІ_В) 

В большинстве схем со страничной организацией памяти таблицы страниц хранят¬ 
ся в памяти из-за их значительного размера. Потенциально такое устройство оказы¬ 
вает колоссальное влияние на производительность. Рассмотрим, например, коман¬ 
ду процессора, копирующую содержимое одного регистра в другой. В отсутствие 
страничной организации памяти эта команда приводит только к одному обращению 
к памяти для выборки самой команды. Если же память организована постранично, 
то будут необходимы дополнительные ссылки для доступа к таблице страниц. Так 
как скорость выполнения команд в основном ограничена скоростью, с которой 
центральный процессор выбирает команды и данные из памяти, необходимость 
двух обращений к таблице страниц на одну ссылку к памяти уменьшает производи¬ 
тельность на 2/3. При таких условиях никто не стал бы использовать этот метод. 

Разработчики компьютеров многие годы размышляли об этой проблеме и в ре¬ 
зультате придумали решение. Оно основано на наблюдении, что большинство про¬ 
грамм склонно делать огромное количество обращений к небольшому количеству 
страниц, а не наоборот. Таким образом, в таблице страниц только малая доля за¬ 
писей читается интенсивно, остальная часть едва ли вообще используется. 

В результате принятого решения компьютер снабжается небольшим аппарат¬ 
ным устройством, служащим для отображения виртуальных адресов в физичес¬ 
кие без прохода по таблице страниц. Эго устройство, называемое буфером быст¬ 
рого преобразования адреса (ТЕВ — Тгапзіаііоп Еооказісіе ВиВег) или иногда 
ассоциативной памятью, продемонстрировано в табл. 4.1. Оно обычно находится 
внутри диспетчера памяти и состоит из нескольких записей. В этом примере их 
восемь, но фактически записей редко бывает больше 64. Каждая запись содержит 
информацию об одной странице, а именно: номер виртуальной страницы, бит, 
устанавливаемый при изменении страницы, код защиты (разрешения на чтение/ 
запись/выполнение) и номер физического страничного блока, в котором располо¬ 
жена эта страница. Эти поля однозначно соответствуют полям в таблице страниц. 
Еще один бит служит признаком того, действительна ли запись (то есть использу¬ 
ется ли она в данный момент) или нет. 
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Таблица 4.1 . Буфер быстрого преобразования памяти для увеличения скорости 
страничной подкачки 


Действительный 

Виртуальная страница 

Изменение 

Защита 

Страничный фрейм 

1 

140 

1 

нѵѵ 

31 

1 

20 

0 

нх 

38 

1 

130 

1 

нѵѵ 

29 

1 

129 

1 

нѵѵ 

62 

1 

19 

0 

нх 

50 

1 

21 

0 

нх 

45 

1 

860 

1 

нѵѵ 

14 

1 

861 

1 

нѵѵ 

75 


Пример, который мог бы сформировать ТЫЗ-буфер, изображенный на 
рис. 4.14, — это циклический процесс, располагающийся в виртуальных страни¬ 
цах 19, 20 и 21, поэтому эти записи в буфере на рис. 4.14 имеют защитные коды 
для чтения и выполнения. Основные данные, используемые в настоящее время 
(скажем, обрабатываемый массив), находятся в страницах 129 и 130. Страница 140 
содержит индексы, требующиеся для вычислений массива. И наконец, в страни¬ 
цах 860 и 861 находится стек. 

Теперь рассмотрим, как же функционирует буфер быстрого преобразования 
адреса (ТЫЗ). Когда виртуальный адрес представляется диспетчером памяти для 
отображения, аппаратура сначала убеждается в том, что номер его виртуальной 
страницы присутствует в буфере ТЫЗ путем сравнения адреса со всеми записями 
одновременно (то есть параллельно). Если найдено имеющее силу совпадение и 
обращение не нарушает биты защиты, страничный блок берется прямо из буфера 
ТЫЗ, без перехода к таблице страниц. Если номер виртуальной страницы присут¬ 
ствует в буфере ТЫЗ, но инструкция пытается записать что-то на страницу, дос¬ 
тупную только для чтения, формируется ошибка защиты точно так же, как это про¬ 
исходило бы из самой таблицы страниц. 

Интересная ситуация получается, если номер виртуальной страницы не нахо¬ 
дится в буфере быстрого преобразования адреса. Диспетчер памяти обнаружива¬ 
ет отсутствие страницы и выполняет обычный поиск в таблице страниц. Затем он 
удаляет одну из записей из буфера ТЫЗ и заменяет ее только что найденной запи¬ 
сью из таблицы страниц. Таким образом, если эта страница снова вскоре будет за¬ 
требована, во второй раз поиск окажется успешным, а не неудачным. Когда запись 
удаляется из буфера быстрого преобразования адреса, бит изменения копируется 
в запись таблицы страниц в памяти. Другие величины уже находятся там. Когда 
буфер ТЫЗ загружается из таблицы страниц, все поля берутся из памяти. 

Программное управление буфером ТЫЗ 

До сих пор мы предполагали, что каждая машина со страничной виртуальной памя¬ 
тью имеет таблицы страниц, распознаваемые аппаратным обеспечением и буфером 
быстрого преобразования адреса. При таком устройстве управление буфером ТЫЗ 
и обработка его ошибок выполняются полностью аппаратурой диспетчера памяти 
(МІѴШ). Передача управления операционной системе происходит только тогда, 
когда страница отсутствует в памяти. 
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В прошлом это допущение было справедливо. Однако многие современные КІ5С- 
компьютеры, включая машины 5РАКС, МІР5, АІрЬа и НР РА, выполняют почти 
все страничное управление программно. На этих машинах записи буферы ТЫЗ 
явно загружаются операционной системой. Когда происходит неудачный поиск 
в буфере ТЫЗ, диспетчер памяти вместо того, чтобы переходить к таблице страниц 
для поиска и выбора необходимой страницы, формирует ошибку буфера ТЫЗ 
и передает проблему в руки операционной системы. Система должна найти страни¬ 
цу, удалить запись из буфера ТЫЗ, ввести новую запись и перезапустить прерван¬ 
ную инструкцию. И, конечно, все это должно быть сделано при помощи неболь¬ 
шого числа команд, потому что неудачи поиска в буфере быстрого преобразования 
адреса происходят намного чаще, чем ошибки из-за отсутствия страниц. 

Достаточно удивительно то, что если буфер ТЬВ имеет небольшой размер (ска¬ 
жем, 64 записи) для понижения частоты неудачных пропусков, программное уп¬ 
равление буфером, оказывается, является приемлемо результативным. Главная 
выгода здесь заключается в намного более простом устройстве диспетчера памяти, 
что освобождает достаточное количество пространства в микросхеме процессора для 
кэша и других устройств, способных повысить производительность. Программное 
управление буфером быстрого преобразования адреса обсуждается в [333]. 

Для улучшения производительности на машинах, программно управляющих 
буфером ТЬВ, разрабатывались различные стратегии поведения. Один подход состо¬ 
ит в попытке уменьшить как частоту неудачного поиска в буфере, так и его стоимость, 
когда он все-таки случается [ 19]. Чтобы уменьшить вероятность неудачного поиска 
в буфере ТЫЗ, иногда операционная система может интуитивно вычислить, какие 
страницы, возможно, будут использоваться следующими и предварительно загру¬ 
зить записи для них в буфер ТЫЗ. Например, когда клиентский процесс посылает 
сообщение серверному процессу на той же самой машине, очень вероятно, что сер¬ 
вер вскоре должен будет начать работу. Зная это, система может также проверить, 
где находятся страницы кода сервера, данных и стека, пока прерывание обрабаты¬ 
вается, чтобы осуществить вызов $епс1, и преобразовать их адреса из виртуальных 
в физические до того, как они смогут стать причиной ошибки ТЬВ-буфера. 

Обычный путь обработки неудачного поиска в буфере ТГВ, аппаратно или про¬ 
граммно — это переход в таблицу страниц и выполнение операции индексации, 
чтобы определить место страницы, к которой происходит обращение. При осуще¬ 
ствлении этого поиска программно возникает проблема, заключающаяся в том, что 
страницы, содержащиеся в таблице страниц, могут отсутствовать в буфере быст¬ 
рого преобразования адреса, что вызовет дополнительные ошибки буфера ТЫЗ во 
время обработки. Их количество можно уменьшить, поддерживая большой (на¬ 
пример, 4 Кбайт) программный кэш записей буфера ТЫЗ с фиксированным рас¬ 
положением в памяти, чьи страницы всегда хранятся в буфере ТЫЗ. Если сначала 
проверять программный кэш, операционная система может в значительной степе¬ 
ни снизить количество неудачных поисков в буфере ТЫЗ. 

Инвертированные таблицы страниц 

Традиционные таблицы страниц, тип которых мы описывали до сих пор, требуют 
по одной записи на каждую виртуальную страницу, так как они индексируются по 
номеру этой страницы. Если адресное пространство состоит из 2 32 байт с размером 
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страницы 4096 байт, тогда в таблице страниц должно быть больше миллиона за¬ 
писей. При этом таблица страниц будет занимать минимум 4 Мбайт. В достаточно 
больших системах это, вероятно, выполнимо. 

Однако поскольку 64-разрядные компьютеры встречаются все чаще, ситуация 
радикально меняется. Если теперь адресное пространство увеличилось до 2 е4 байт 
с размером страницы 4 Кбайт, нам требуется таблица страниц с 2 52 записями. Если 
каждая запись равна 8 байтам, таблица займет больше 30 Тбайт. Выделение 30 Тбайт 
только для таблицы страниц нереально сейчас и не будет реальным когда-либо 
в будущем. Следовательно, для 64-разрядного страничного виртуального про¬ 
странства необходимо другое решение. 

Одним из таких решений является инвертированная таблица страниц. В этой 
модели таблица содержит по одной записи на страничный блок в реальной памя¬ 
ти, а не на страницу в виртуальном адресном пространстве. Например, при 64-раз- 
рядных виртуальных адресах, размере страниц 4 Кбайт и 256 Мбайт оперативной 
памяти инвертированная таблица страниц потребует всего лишь 65 536 записей. 
Каждая запись отслеживает, что (процесс, виртуальная страница) расположено 
в данном страничном блоке. 

Хотя инвертированные таблицы страниц экономят значительное количество 
места, по крайней мере, когда виртуальное адресное пространство намного боль¬ 
ше, чем физическая память, они имеют серьезный недостаток: перевод виртуаль¬ 
ного адреса в физический становится намного сложнее. Когда процесс п обраща¬ 
ется к виртуальной странице/), аппаратное обеспечение не может больше найти 
физическую страницу, используя номер р в качестве индекса в таблице страниц. 
Вместо этого оно должно производить поиск записи ( п,р ) во всей инвертирован¬ 
ной таблице страниц. Более того, этот поиск должен выполняться при каждом 
обращении к памяти, а не только при страничном прерывании. Операция поиска 
в таблице размером 64 К при каждой ссылке к памяти вовсе не увеличит скорость 
вашей машины. 

Выйти из этого затруднительного положения можно, используя буфер быстро¬ 
го преобразования адреса (ТЬВ). Если буфер ТЬВ может содержать все часто 
используемые страницы, трансляция адреса будет происходить так же быстро, как 
и с обычными таблицами страниц. Но при неудачном поиске в буфере ТЬВ поиск 
в инвертированной таблице страниц должен выполняться программно. Один из 
возможных способов усовершенствовать его — поддерживать хэш-таблицу вирту¬ 
альных адресов. Все виртуальные страницы, находящиеся в данный момент в па¬ 
мяти и имеющие одинаковое значение хэш-функции, сцепляются друг с другом, 
как показано на рис. 4.14. Если хэш-таблица состоит из такого же количества яче¬ 
ек, сколько в машине физических страниц, средняя цепочка будет длиной толь¬ 
ко в одну запись, что значительно увеличит скорость отображения адресов. Как 
только найден номер страничного блока, новая пара (виртуальная, физическая) 
помещается в буфер ТЬВ. 

Инвертированные таблицы страниц в настоящее время используются на неко¬ 
торых рабочих станциях компаний ІВМ и Нелѵіеи-Раскагб и будут встречаться все 
чаще, так как 64-разрядные машины получают все более широкое распростра¬ 
нение. Некоторые другие методы управления виртуальной памятью большого 
размера можно найти в [159, 320, 321]. 
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Рис. 4.14. Сравнение традиционной таблицы страниц с инвертированной 


Алгоритмы замещения страниц 

Когда происходит страничное прерывание, операционная система должна выбрать 
страницу для удаления из памяти, чтобы освободить место для страницы, кото¬ 
рую нужно перенести в память. Если удаляемая страница была изменена за время 
своего присутствия в памяти, ее необходимо переписать на диск, чтобы обновить 
копию, хранящуюся там. Однако если страница не была модифицирована (на¬ 
пример, она содержит текст программы), копия на диске уже является самой но¬ 
вой и ее не надо переписывать. Тогда страница, которую нужно прочитать, просто 
считывается поверх выгружаемой страницы. 

Хотя в принципе можно при каждом страничном прерывании выбирать случай¬ 
ную страницу для удаления из памяти, производительность системы заметно по¬ 
вышается, когда предпочтение отдается редко используемой странице. Если вы¬ 
гружается страница, обращения к которой происходят часто, велика вероятность, 
что вскоре опять потребуется ее возврат в память, что даст в результате дополни¬ 
тельные издержки. Теме разработки алгоритмов замены страницы было посвяще¬ 
но много работ, как теоретических, так и экспериментальных. Ниже мы опишем 
некоторые из наиболее важных алгоритмов. 

Следует отметить, что проблема «страничного обмена» также встает и в других 
областях конструирования компьютеров. Например, у большинства компьютеров 
есть один или несколько кэшей, состоящих из используемых в последнее время 
32-байтовых или 64-байтовых блоков памяти. Когда кэш заполнен, необходимо 
выбрать некоторые блоки для удаления. Эта проблема практически аналогична 
замещению страниц лишь с одной разницей, заключающейся в меньшем масштабе 
времени (операция должна быть выполнена за несколько наносекунд, а не милли¬ 
секунд, как для замены страниц). Причиной для более короткого промежутка вре¬ 
мени является то, что неудачный поиск блока в кэше обрабатывается из основной 



246 


Глава 4. Управление памятью 


памяти, в которой не тратится время на поиск нужного цилиндра диска и нет за¬ 
держки из-за его вращения. 

Второй пример встречается на \ѵеЬ-серверах. Сервер может хранить определен¬ 
ное количество часто используемых \ѵеЬ-страниц в своей кэш-памяти. Однако ког¬ 
да кэш-память заполняется целиком и происходит обращение к новой странице, 
должно приниматься решение о том, какую из страниц выгружать. Здесь приме¬ 
нимы те же рассуждения, что и для страниц в виртуальной памяти, с той разни¬ 
цей, что ѵѵеЬ-страницы никогда не изменяются в кэше, поэтому для них всегда есть 
свежая копия на диске. В системе виртуальной памяти страницы в оперативной 
памяти могут быть «чистыми» или «грязными». 

Оптимальный алгоритм 

Наилучший из возможных алгоритмов замещения страниц легко описать, но не¬ 
возможно осуществить. Он действует так. В тот момент, когда происходит стра¬ 
ничное прерывание, в памяти находится некоторый набор страниц. К одной из этих 
страниц будет обращаться следующая команда процессора (к странице, содержа¬ 
щей требуемую команду). На другие страницы, возможно, не будет ссылок в тече¬ 
ние следующих 10,100 или даже 1000 команд. Каждая страница может быть поме¬ 
чена количеством команд, которые будут выполняться перед первым обращением 
к этой странице. 

Оптимальный страничный алгоритм просто сообщает, что должна быть выгру¬ 
жена страница с наибольшей меткой. Если одна страница не будет использоваться 
в течение 8 млн команд, а другая — в течение 6 млн инструкций, удаление первой 
отодвинет в будущее на возможно максимальный срок страничное прерывание, 
которое вернет ее назад. Компьютеры, подобно людям, пытаются отложить непри¬ 
ятные события настолько, насколько это возможно. 

С этим алгоритмом связана только одна проблема: он невыполним. В момент 
страничного прерывания операционная система не имеет возможности узнать, 
когда произойдет следующее обращение к каждой странице. (Мы рассматривали 
аналогичную ситуацию раньше, когда обсуждали алгоритм планирования «кратчай¬ 
шая задача — первая»: как система может сказать, какая из задач самая короткая?) 
Тем не менее, выполняя программу на модели и следя за всеми обращениями к стра¬ 
ницам, оптимальную замену можно осуществить при втором запуске, используя 
информацию о ссылках на страницы, собранную во время первого запуска. 

В этом случае можно сравнивать производительность реализуемых алгорит¬ 
мов с наилучшим. Если операционная система добивается производительности, 
скажем, всего на один процент ниже, чем при работе оптимального алгоритма, 
усилия, потраченные на поиск лучшего алгоритма, повысят продуктивность схе¬ 
мы максимум на 1 %. 

Чтобы избежать возможных недоразумений, следует прояснить, что полученный 
протокол обращений к страницам относится только к одной хорошо спланирован¬ 
ной программе и, кроме того, к определенным входным данным. Таким образом, алго¬ 
ритм замещения страниц, выведенный из него, будет характерен только для этой 
программы с именно этими входными данными. Хотя такой метод полезен для оцен¬ 
ки алгоритмов замещения страниц, он не используется в практических системах. 
Ниже мы изучим алгоритмы, которые являются применимыми в реальных системах. 
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Алгоритм ІЧКІІ — не использовавшаяся 
в последнее время страница 

Чтобы дать возможность операционной системе собирать полезные статисти¬ 
ческие данные о том, какие страницы используются, а какие — нет, большинство 
компьютеров с виртуальной памятью поддерживают два статусных бита, связанных 
с каждой страницей. Бит К (Кеіегепсесі — обращения) устанавливается всякий раз, 
когда происходит обращение к странице (чтение или запись). БитМ (МосШіесІ — 
изменение) устанавливается, когда страница записывается (то есть изменяется). 
Биты содержатся в каждом элементе таблицы страниц, как показано на рис. 4.13. 
Важно реализовать обновление этих битов при каждом обращении к памяти, по¬ 
этому необходимо, чтобы они задавались аппаратно. Если однажды бит был уста¬ 
новлен в 1, то он остается равным 1 до тех пор, пока операционная система про¬ 
граммно не вернет его в состояние 0. 

Если аппаратное обеспечение не поддерживает эти биты, их можно смодели¬ 
ровать следующим образом. Когда процесс запускается, все его записи в таблице 
страниц помечаются как отсутствующие в памяти. Как только происходит обра¬ 
щение к странице, происходит страничное прерывание. Затем операционная сис¬ 
тема устанавливает бит К (в своих внутренних таблицах); изменяет запись в таб¬ 
лице страниц, чтобы она указывала на корректную страницу с режимом КЕАЭ 
ОЫБУ (только для чтения), и перезапускает команду. Если страница позднее за¬ 
писывается, происходит другое страничное прерывание, позволяющее операцион¬ 
ной системе установить бит М и изменить состояние страницы на КЕАО/АѴКІТЕ 
(чтение/запись). 

Биты КкМ могут использоваться для построения простого алгоритма замещения 
страниц, описанного ниже. Когда процесс запускается, оба страничных бита для 
всех его страниц операционной системой установлены на 0. Периодически (например, 
при каждом прерывании по таймеру) бит К очищается, чтобы отличить страницы, 
к которым давно не происходило обращения от тех, на которые были ссылки. 

Когда возникает страничное прерывание, операционная система проверяет 
все страницы и делит их на четыре категории на основании текущих значений 
битов КкМ: 

Класс 0: не было обращений и изменений. 

Класс 1: не было обращений, страница изменена. 

Класс 2; было обращение, страница не изменена. 

Класс 3: произошло и обращение, и изменение. 

Хотя класс 1 на первый взгляд кажется невозможным, такое случается, когда 
у страницы из класса 3 бит К сбрасывается во время прерывания по таймеру. Пре¬ 
рывания по таймеру не стирают бит М, потому что эта информация необходима 
для того, чтобы знать, нужно ли переписывать страницу на диске или нет. Поэто¬ 
му если бит К устанавливается на ноль, а М остается нетронутым, страница попа¬ 
дает в класс 1. 

Алгоритм N11(3 (N 0 ! Кесепііу №ес1 — не использовавшийся в последнее время) 
удаляет страницу с помощью случайного поиска в непустом классе с наименьшим 
номером. В этом алгоритме подразумевается, что лучше выгрузить измененную 
страницу, к которой не было обращений по крайней мере в течение одного тика 
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системных часов (обычно 20 мс), чем стереть часто используемую страницу. При¬ 
влекательность алгоритма N1111 заключается в том, что он легок для понимания, 
умеренно сложен в реализации и дает производительность, которая, конечно, не 
оптимальна, но может вполне оказаться достаточной. 

Алгоритм РІРО — первым прибыл — 
первым обслужен 

Другим требующим небольших издержек алгоритмом является РІРО (РігзІ-Іп, 
РігзІ-ОиІ — «первым прибыл — первым обслужен»). Чтобы проиллюстрировать 
его работу, рассмотрим универсам, на полках которого можно выставить ровно к 
различных продуктов. Он предлагает новую удобную пищу: растворимый, глубо¬ 
ко замороженный, экологически чистый йогурт, который можно мгновенно при¬ 
готовить в микроволновой печи. Покупатели тут же обратили внимание на этот 
продукт, поэтому наш ограниченный в размерах супермаркет, для того чтобы про¬ 
давать йогурт, должен избавиться от одного из старых товаров. 

Один из вариантов состоит в том, чтобы найти продукт, который супермаркет 
продает дольше всего (то есть что-нибудь, что начали реализовывать 120 лет на¬ 
зад), и освободить от него магазин на том основании, что им никто больше не ин¬ 
тересуется. В действительности супермаркет хранит перечень всех продаваемых 
в данный момент товаров, упорядоченный по времени их появления. Каждый 
новый продукт помещается в конец перечня, а из начала списка удаляется одно 
старое наименование. 

Ту же самую идею можно применить в качестве алгоритма замещения страниц. 
Операционная система поддерживает список всех страниц, находящихся в данный 
момент в памяти, в котором первая страница является старейшей, а страницы в 
хвосте списка попали в него совсем недавно. Когда происходит страничное пре¬ 
рывание, выгружается из памяти страница в голове списка, а новая страница до¬ 
бавляется в его конец. Если алгоритм РІРО использовать в магазине, то он может 
удалить воск для усов, но также может удалить и муку, соль или масло. Примени¬ 
тельно к компьютерам возникает та же проблема. По этой причине алгоритм РІРО 
редко используется в своей исходной форме. 

Алгоритм «вторая попытка» 

В простейшем варианте алгоритма РІРО, который, позволяет избежать проблемы 
вытеснения из памяти часто используемых страниц, у самой старейшей страницы 
изучается бит К. Если он равен 0, страница не только находится в памяти долго, 
она вдобавок еще и не используется, поэтому немедленно заменяется новой. Если 
же бит К равен 1, то ему присваивается значение 0, страница переносится в конец 
списка, а время ее загрузки обновляется, то есть считается, что страница только 
что попала в память. Затем процедура продолжается. 

Работа этого алгоритма, называемого «второй попыткой» (зесопсі сЬапсе), 
показана на рис. 4.15, а. Здесь изображены страницы от А до Я, хранящиеся в свя¬ 
занном списке и отсортированные по времени их поступления в память. Числа над 
страницами обозначают их время загрузки в память. 
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Предположим, что в момент времени 20 происходит страничное прерывание. 
Самой старшей страницей является страница А, она была загружена в память во 
время 0, когда начал работу процесс. Если бит К страницы А равен 0, она выгружа¬ 
ется из памяти или путем записи на диск (если страница «грязная»), или просто 
удаляется (если она «чистая»). Во втором случае, если бит К равен 1, страница А 
передвигается в конец списка, а ее «загрузочное время» принимает текущее зна¬ 
чение (20). При этом бит К очищается 1 . Поиск подходящей страницы продолжа¬ 
ется; следующей проверяется страница В. 

Страница, 

загруженная первой Последняя 



а 



А трактуется 
как заново 

загруженная страница 


б 


Рис. 4.15. Действие алгоритма «вторая попытка»: страницы, отсортированные в порядке 
очереди (РІРО) (а); список страниц, если страничное прерывание произошло 
во время 20, а страница А имеет бит Я, равный 0 (б) 


Алгоритм «вторая попытка» ищет в списке самую старую страницу, к кото¬ 
рой не было обращений в предыдущем временном интервале. Если же происхо¬ 
дили ссылки на все страницы, то «вторая попытка» превращается в обычный 
алгоритм РІРО. Представьте, что у всех страниц на рис. 4.15, а бит К равен 1. Одну 
за другой передвигает операционная система страницы в конец списка, очищая 
бит К каждый раз, когда она перемещает страницу в хвост. Наконец, она вернется 
к странице А, но теперь уже ее биту К присвоено значение 0. В этот момеш 
страница А выгружается из памяти. Таким образом, алгоритм всегда успешно за¬ 
вершает свою работу. 


Алгоритм «часы» 

Хотя алгоритм «вторая попытка» является корректным, он слишком неэффекти¬ 
вен, потому что постоянно передвигает страницы по списку. Поэтому лучше хра¬ 
нить все страничные блоки в кольцевом списке в форме часов, как показано на 
рис. 4.16. Стрелка указывает на старейшую страницу. 

Когда происходит страничное прерывание, проверяется та страница, на кото¬ 
рую направлена стрелка. Если ее бит К равен 0, страница выгружается, на ее место 
в часовой круг встает новая страница, а стрелка сдвигается вперед на одну пози¬ 
цию. Если бит К равен 1, то он сбрасывается, стрелка перемещается к следующей 
странице. Этот процесс повторяется до тех пор, пока не находится та страница, 


То есть устанавливается на 0. — Примем, перев. 
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у которой бит К = 0. Неудивительно, что этот алгоритм называется «часы». Он от¬ 
личается от алгоритма «вторая попытка» только своей реализацией. 


□ 


В 


в 




Когда происходит страничное 
прерывание, поверяется страница, 
на которую указывает стрелка. 
Предпринимаемые действия 
зависят от бита К: 

К=0: страница выгружается 

К=1: бит К сбрасывается, стрелка 
движется вперед 


Рис. 4.16. Алгоритм замещения страниц «часы» 


Алгоритм ЬНІІ — страница, 
не использовавшаяся дольше всего 

В основе этой неплохой аппроксимации оптимального алгоритма лежит наблюде¬ 
ние, что страницы, к которым происходило многократное обращение в несколь¬ 
ких последних командах, вероятно, также будут часто использоваться в следую¬ 
щих инструкциях. И наоборот, можно полагать, что страницы, к которым ранее не 
возникало обращений, не будут употребляться в течение долгого времени. Эта идея 
привела к следующему реализуемому алгоритму: когда происходит страничное пре¬ 
рывание, выгружается из памяти страница, которая не использовалась дольше все¬ 
го. Такая стратегия замещения страниц называется ЫШ (ЬеазС Кесепііу 11 зесі — 
«менее недавно», то есть наиболее давно использовавшаяся страница). 

Хотя алгоритм ЫШ теоретически реализуем, он не является дешевым. Для пол¬ 
ного осуществления алгоритма ВІШ необходимо поддерживать связный список 
всех содержащихся в памяти страниц, где последняя использовавшаяся страница 
находится в начале списка, а та, к которой дольше всего не было обращений, — в кон¬ 
це. Сложность заключается в том, что список должен обновляться при каждом об¬ 
ращении к памяти. Поиск страницы, ее удаление, а затем вставка в начало списка — 
это операции, поглощающие очень много времени, даже если они выполняются аппа¬ 
ратно (если предположить, что необходимое оборудование можно сконструировать). 

Однако существуют другие способы реализации алгоритма ЫШ с помощью 
специального оборудования. Для первого метода требуется оснащение компьютера 
64-разрядным аппаратным счетчиком С, который автоматически возрастает по¬ 
сле каждой команды. Кроме того, каждая запись в таблице страниц должна иметь 
поле, достаточно большое для хранения значения счетчика. После каждого обра¬ 
щения к памяти текущая величина счетчика С запоминается в записи таблицы, со¬ 
ответствующей той странице, к которой произошла ссылка. А если возникает стра- 
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ничное прерывание, операционная система проверяет все значения счетчиков в 
таблице страниц и ищет наименьшее. Эта страница является не использовавшей¬ 
ся дольше всего. 

Теперь рассмотрим второй вариант аппаратной реализации алгоритма ЫШ. На 
машине с п страничными блоками оборудование ЫШ может поддерживать мат¬ 
рицу пхп бит, изначально равных нулю. Всякий раз, когда происходит обращение 
к страничному блоку к, аппаратура сначала присваивает всем битам строки к зна¬ 
чение 1, затем приравнивает к нулю все биты столбца к. В любой момент времени 
строка, двоичное значение которой наименьшее, является не использовавшейся 
дольше всего. Работа этого алгоритма продемонстрирована на рис. 4,17, где рассмат¬ 
риваются четыре страничных блока и следующий порядок обращения к страницам: 

0123210323 


После ссылки на страницу 0 мы получаем ситуацию, показанную на рис. 4.17, а; 
после обращения к странице 1 — рис. 4.17, б и т. д. 


Страница 


Страница 



0 

1 

2 

3 

0 

0 

1 

1 

1 

1 

0 

0 

0 

0 

2 

0 

0 

0 

0 

3 

0 

0 

0 

0 


О 1 


0 

0 

1 

1 

1 

0 

1 

1 

0 

0 

0 

0 

0 

0 

0 

0 


Страница 
0 12 3 


0 

0 

0 

1 

1 

0 

0 

1 

1 

1 

0 

1 

0 

0 

0 

0 


Страница 
0 12 3 


0 

0 

0 

0 

1 

0 

0 

0 

1 

1 

0 

0 

1 

1 

1 

0 


Страница 
0 12: 


0 

0 

0 

0 

1 

0 

0 

0 

1 

1 

0 

1 

1 

1 

0 

0 


0 

0 

0 

0 

1 

0 

1 

1 

1 

0 

0 

1 

1 

0 

0 

0 


е 


0 

1 

1 

1 

0 

0 

1 

1 

0 

0 

0 

1 

0 

0 

0 

0 


ж 


0 

1 

1 

0 

0 

0 

1 

0 

0 

0 

0 

0 

1 

1 

1 

0 


з 


0 

1 

0 

0 

0 

0 

0 

0 

1 

1 

0 

1 

1 

1 

0 

0 


и 


0 

1 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

1 

1 

1 

0 


к 


Рис. 4.17. Алгоритм ЬРЮ, использующий матрицу. Обращения к страницам 
происходят в порядке: 0, 1,2, 3, 2, 1,0, 3, 2, 3 


Программное моделирование алгоритма І_ПІІ 

Хотя оба описанных выше алгоритма ЫШ в принципе осуществимы, очень мало 
(если вообще такие есть) машин оснащено подобным оборудованием, поэтому раз¬ 
работчики операционных систем для компьютеров, не имеющих такой аппарату¬ 
ры, редко используют эти алгоритмы. Вместо этого требуется программно реали¬ 
зуемое решение. Одна из разновидностей схемы ЫШ называется алгоритмом ОТ11 
(Ыоі Ргециепііу Ивес! — редко использовавшаяся страница). Для него необходим 
программный счетчик, связанный с каждой страницей в памяти, изначально равный 
нулю. Во время каждого прерывания по таймеру операционная система исследует 




252 


Глава 4. Управление памятью 


все страницы ь памяти. Бит К каждой страницы (он равен 0 или 1) прибавляется к 
счетчику. В сущности, счетчики пытаются отследить, как часто происходило обра¬ 
щение к каждой странице. При страничном прерывании для замещения выбира¬ 
ется страница с наименьшим значением счетчика. 

Основная проблема, возникающая при работе с алгоритмом ЫРІІ, заключается 
в том, что он никогда ничего не забывает. Например, в многоходовом компилято¬ 
ре страницы, которые часто использовались во время первого прохода, могут все 
еще иметь высокое значение счетчика при более поздних проходах. Фактически, 
если случается так, что первый проход занимает самое долгое время выполнения 
из всех, страницы, содержащие программный код для следующих проходов, могут 
всегда иметь более низкое значение счетчика, чем страницы первого прохода. Сле¬ 
довательно, операционная система удалит полезные страницы вместо тех, которые 
больше не нужны. 

К счастью, небольшая доработка алгоритма ЫРИ делает его способным моде¬ 
лировать алгоритм ЫШ достаточно хорошо. Изменение состоит из двух частей. 
Во-первых, каждый счетчик сдвигается вправо на один разряд перед прибавлени¬ 
ем бита К. Во-вторых, бит К добавляется в крайний слева, а не в крайний справа 
бит счетчика. 

На рис. 4.18 продемонстрировано, как работает видоизмененный алгоритм, из¬ 
вестный под названием «старение» (а§іп§). Предположим, что после первого тика 
часов биты К для страниц от 0 до 5 имеют значения 1,0, 1,0, 1, 1 соотвественно 
(у страницы 0 бит К равен 1, у страницы 1 К = 0, у страницы 2 К = 1 и т. д.). Други¬ 
ми словами, между тиком 0 и тиком 1 произошло обращение к страницам 0, 2, 4 
и 5, их биты К приняли значение 1, остальные сохранили значение 0. После того 
как шесть соответствующих счетчиков сдвинулись на разряд и бит К занял край¬ 
нюю слева позицию, счетчики получили значения, показанные на рис. 4.18, а. 
Остальные четыре колонки рисунка изображают шесть счетчиков после следую¬ 
щих четырех тиков часов. 

Когда происходит страничное прерывание, удаляется та страница, чей счетчик 
имеет наименьшую величину. Ясно, что счетчик страницы, к которой не было об¬ 
ращений, скажем, за четыре тика, будет начинаться с четырех нулей и, таким обра¬ 
зом, иметь более низкое значение, чем счетчик страницы, на которую не ссылались 
в течение только трех тиков часов. 

Эта схема отличается от алгоритма ЫШ в двух случаях. Рассмотрим страни¬ 
цы 3 и 5 на рис. 4.18, д. Ни к одной из них не было обращений за последние два тика, 
к обеим было обращение за предшествующий этому тик. Следуя алгоритму ЫШ, 
при удалении страницы из памяти мы должны выбрать одну из этих двух. Пробле¬ 
ма в том, что мы не знаем, к какой из них позже произошло обращение в интервале 
времени между тиками 1 и 2. Записывая только один бит за промежуток времени, 
мы теряем возможность отличить более ранние от более поздних обращений в этом 
интервале времени. Все, что мы можем сделать — это выгрузить страницу 3, пото¬ 
му что к странице 5 также обращались двумя тиками раньше, а к странице 3 — нет. 

Второе отличие между алгоритмами ЫШ и «старения» заключается в том, что 
в последнем счетчик имеет конечное число разрядов, например 8. Предположим, 
что каждая из двух страниц имеет значение счетчика, равное 0. В данной ситуа¬ 
ции мы только случайным образом можем выбрать одну из них. На самом деле 
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может оказаться, что к одной странице в последний раз обращались 9 тиков назад, 
а к другой — 1000. И мы не имеем возможности увидеть это. На практике, однако, 
обычно достаточно 8 битов при тике системных часов около 20 мс. Если к страни¬ 
це не обращались в течение 160 мс, очень вероятно, что она не важна. 
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Рис. 4.18. Алгоритм старения программно моделирует алгоритм І-ЙЫ. 
Здесь изображены шесть страниц после пяти тиков часов от (а) до ( д) 


Алгоритм «рабочий набор» 

В простейшей схеме страничной подкачки в момент запуска процессов нужные им 
страницы отсутствуют в памяти. Как только центральный процессор пытается 
выбрать первую команду, он получает страничное прерывание, побуждающее опе¬ 
рационную систему перенести в память страницу, содержащую первую инструк¬ 
цию. Обычно следом быстро происходят страничные прерывания для глобальных 
переменных и стека. Через некоторое время в памяти скапливается большинство 
необходимых процессу страниц, и он приступает к работе с относительно неболь¬ 
шим количеством ошибок из-за отсутствия страниц. Этот метод называется заме¬ 
щением страниц по запросу (бетапб ра§іп§), потому что страницы загружаются 
в память по требованию, а не заранее. 

Конечно, достаточно легко написать тестовую программу, систематически чи¬ 
тающую все страницы в огромном адресном пространстве, вызывая так много стра¬ 
ничных прерываний, что будет не хватать памяти для их обработки. К счастью, 
большинство процессов не работают таким образом. Они характеризуются локаль¬ 
ностью обращений, означающей, что во время выполнения любой фразы процесс 
обращается только к сравнительно небольшой части своих страниц. Каждый про¬ 
ход многоходового компилятора, например, обращается только к части от общего 
количества страниц, и каждый раз к другой части. 
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Множество страниц, которое процесс использует в данный момент, называет¬ 
ся рабочим набором ([89, 92]). Если рабочий набор целиком находится в памяти, 
процесс будет работать, не вызывая большого количества ошибок, до тех пор пока 
он не перейдет к другой фазе выполнения (то есть к следующему проходу компи¬ 
лятора). Если доступная память слишком мала для того, чтобы содержать полный 
рабочий набор, процесс вызовет много страничных прерываний и будет работать 
медленнее, так как выполнение инструкции занимает несколько наносекунд, а чте¬ 
ние страницы с диска обычно требует 10 мс. При скорости одна или две команды 
за Юме для завершения программы понадобятся века. Говорят, что программа, 
вызывающая страничное прерывание каждые несколько команд, пробуксовыва¬ 
ет (іЬгазЬіпд) [90]. 

В многозадачных системах процессы часто перемещаются на диск (то есть все 
их страницы удаляются из памяти), чтобы позволить другим процессам получить 
доступ к центральному процессору. Возникает вопрос, что делать, когда процесс 
снова загружается в память. С формальной точки зрения делать ничего не нужно. 
Процесс будет вызывать одно за другим страничные прерывания до тех пор', пока 
не загрузится в память весь его рабочий набор. Проблема в том, что наличие 20, 
100 или даже 1000 страничных прерываний при каждой загрузке процесса сильно 
замедляет работу системы и, кроме того, тратит впустую значительное количество 
времени работы центрального процессора, так как обработка страничного прерыва¬ 
ния операционной системой требует нескольких миллисекунд работы процессора. 

Поэтому многие системы со страничной организацией пытаются отслеживать 
рабочий набор каждого процесса и обеспечивают его нахождение в памяти до 
запуска процесса. Такой подход носит название модели рабочего набора [91]. 
Он разработан для того, чтобы значительно снизить процент страничных преры¬ 
ваний. Загрузка страниц перед тем, как разрешить процессу работать, также назы¬ 
вается опережающей подкачкой страниц (ргера§іп§). Заметьте, что рабочий на¬ 
бор изменяется с течением времени. 

Давно известно, что большинство программ не обращаются к своему адресно¬ 
му пространству равномерно; чаще всего ссылки группируются на небольшом ко¬ 
личестве страниц. Обращение к памяти может быть выборкой команды, данных 
или сохранением данных. В любой момент времени і существует множество стра¬ 
ниц, использовавшихся за к последних обращений к памяти. Это множество т(к, I) 
и есть рабочий набор. Так как все недавние обращения к памяти для к > 1 обяза¬ 
тельно должны были обращаться ко всем страницам, использовавшимся для к = 1 
обращения к памяти, то есть к последней и, возможно, еще к некоторым страни¬ 
цам, ѵв{к, і) является монотонно неубывающей функцией от к. Функция т(к, I) 
ограничена для больших к, потому что программа не может обращаться к боль¬ 
шему количеству страниц, чем содержится в ее адресном пространстве, кроме 
того, редкие программы обращаются ко всем страницам адресного пространства. 
На рис. 4.19 изображена зависимость размера рабочего набора от к. 

Тот факт, что большинство программ случайным образом обращается к неболь¬ 
шому числу страниц, но это множество медленно изменяется во времени, объяс¬ 
няет быстрое возрастание функции в начале и затем медленное увеличение для 
больших к. Например, программа, которая выполняет цикл, затрагивающий две 
страницы и использующий данные на четырех страницах, может обращаться ко 
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всем шести страницам через каждые 1000 инструкций, но самое последнее обра¬ 
щение к некоторым другим страницам могло произойти миллионом команд рань¬ 
ше, во время начальной загрузки фазы. Вследствие этого асимптотического ха¬ 
рактера содержимое рабочего набора не чувствительно к выбранной величине к. 
Существует широкий диапазон значений к , для которых рабочий набор постоянен. 
Поскольку рабочий набор медленно меняется со временем, можно сделать разум¬ 
ное предположение, что те страницы, которые будут нужны для возобновления 
работы программы, составляют основу рабочего набора во время последней оста¬ 
новки процесса. Опережающая подкачка страниц заключается в загрузке рабоче¬ 
го набора до того, как процессу разрешается возобновиться. 



Рис. 4.19. Рабочий набор — это множество страниц, используемых к последними обращениями 
к памяти. Функция ѵѵ(к, I) представляет собой размер рабочего набора в момент времени 1 

Чтобы реализовать модель рабочего набора, необходимо, чтобы операционная 
система отслеживала, какие страницы в нем находятся. Наличие этой информа¬ 
ции также немедленно приводит к возможному алгоритму замещения страниц: 
когда происходит страничное прерывание, ищется и выгружается страница, не 
находящаяся в рабочем наборе. Для реализации такого алгоритма нужен точный 
метод определения того, какая страница находится в рабочем наборе, а какая в него 
не включена в любой заданный момент времени. 

Как мы упоминали выше, рабочим набором является множество страниц, ис¬ 
пользовавшихся в к последних обращениях к памяти (некоторые авторы исполь¬ 
зуют к последних страничных обращений, но выбор произволен). Для осуществ¬ 
ления алгоритма «рабочий набор» заранее нужно назначить значение к. Как только 
некоторая величина выбрана, после каждого обращения к памяти набор страниц, 
используемых за предыдущие к обращений, определяется единственным образом. 

Конечно, наличие действующего определения рабочего набора вовсе не озна¬ 
чает, что существует эффективный способ отслеживания его в реальном времени, 
то есть во время выполнения программы. Можно было бы придумать сдвигаю¬ 
щийся регистр длины к, который смещается влево на одну позицию при каждом 
обращении к памяти и записывает номер последней использовавшейся страницы 
в крайнюю правую позицию. Все к номеров страниц в сдвигающемся регистре 
входили бы в рабочий набор. Теоретически в момент страничного прерывания со¬ 
держимое этого регистра могло бы считываться и сохраняться. Затем удалялись 
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бы дублирующиеся страницы. В результате мы бы получали рабочий набор. Одна¬ 
ко поддержка сдвигающегося регистра и его обработка при страничном прерывании 
чрезвычайно дороги, поэтому данная техника никогда не употребляется на деле. 

Вместо нее используются различные аппроксимации. Применяемый в большин¬ 
стве случаев подход заключается в том, чтобы оставить идею подсчета к последних 
обращений к памяти и вместо этого использовать время выполнения программы. 
Например, вместо определения рабочего набора как множества страниц, на кото¬ 
рые ссылались при предыдущих 10 млн обращений к памяти, мы можем опреде¬ 
лить его как множество страниц, использовавшихся в течение последних 100 мс 
времени выполнения. На практике это определение имеет тот же смысл, но намно¬ 
го упрощает реализацию алгоритма. Заметим, что для каждого процесса считается 
только его собственное время работы. Таким образом, если процесс стартовал во 
время Т и занял процессор на 40 мс за реальное время Т+ 100 мс, для определения 
рабочего набора его время равно 40 мс. Время работы процессора, которое фак¬ 
тически использовал процесс с момента запуска, часто называется текущим 
виртуальным временем. При таком приближении рабочий набор процесса — это 
множество страниц, к которому он обращался за последние т секунд виртуального 
времени. 

Теперь рассмотрим алгоритм замещения страниц, основанный на рабочем на¬ 
боре. Его базовая идея заключается в том, чтобы найти страницу, не включенную 
в рабочий набор, и выгрузить ее. На рис. 4.20 изображена часть таблицы страниц 
для некоторой машины. Поскольку в качестве кандидатов на удаление рассматри¬ 
ваются только те страницы, которые в настоящее время находятся в памяти, от¬ 
сутствующие в памяти страницы этим алгоритмом игнорируются. Каждая запись 
содержит (по крайней мере) два элемента информации: приближенное время, 
в которое страница использовалась в последний раз, и бит Я (обращения). Пустые 
белые прямоугольники символизируют другие поля, ненужные для данного алго¬ 
ритма, такие как номер страничного блока, биты защиты и бит М (изменения). 

Алгоритм работает следующим образом. Предполагается, что аппаратное обес¬ 
печение устанавливает биты ЯпМ, как мы описывали выше. Предполагается также, 
что периодическое прерывание по таймеру вызывает запуск программы, очищаю¬ 
щей бит Я при каждом тике часов. При каждом страничном прерывании исследу¬ 
ется таблица страниц и ищется страница, подходящая для удаления из памяти. 

В процессе обработки каждой записи проверяется бит Я. Если он равен 1, теку¬ 
щее виртуальное время записывается в поле Время последнего использования ( Тіте 
о/іазі изе) в таблице страниц, указывая, что страница использовалась в тот момент, 
когда произошло прерывание. Так как к странице было обращение в течение дан¬ 
ного такта, ясно, что она находится в рабочем наборе и не является кандидатом на 
удаление (предполагается, что т охватывает несколько тиков часов). 

Если бит Я равен 0, это означает, что к странице не было обращений в течение 
последнего тика часов и она может быть кандидатом на удаление. Чтобы понять, 
нужно ли ее выгружать, вычисляется ее возраст, то есть текущее виртуальное вре¬ 
мя минус ее Время последнего использования, и сравнивается с т. Если возраст боль¬ 
ше величины т, это означает, что страница более не находится в рабочем наборе. 
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Она стирается, а на ее место загружается новая страница. Однако сканирование 
таблицы продолжается, обновляя остальные записи. 

I 2204 I Текущее виртуальное время 


Информация 
об одной странице 


Время последнего 
использования 


К странице было 
обращения за данный 
такт 


К странице не было 
обращения за данный 
такт 

Таблица страниц 



2084 | 1 


2003 I 1 


-► 1980 | 1 


1213 | 0 

У 

2014 | 1 


2020 | 1 


2032 I 1 

1620 ІО 


Бит К (обращение) 


При изучении всех страниц 
проверяется бит К: 

если (К==1), 

текущее виртуальное время запоминается 
в поле времени последнего использования 

если (К==0 и возраст > і), 
удаляется эта страница 

если (К==0 и возраст < і), 
запоминается наименьшее время 


Рис. 4.20. Алгоритм «рабочий набор» 


Если же бит К равен 0, но возраст страницы меньше или равен времени т, это 
значит, что страница до сих пор находится в рабочем наборе. Она временно обхо¬ 
дится, но страница с наибольшим возрастом запоминается (наименьшим значени¬ 
ем Времени последнего использования). Если проверена вся таблица, а кандидат на 
удаление не найден, это означает, что все страницы входят в рабочий набор. В этом 
случае, если были найдены одна или больше страниц с битом Я = 0, удаляется та 
из них, которая имеет наибольший возраст. В худшем случае ко всем страницам 
произошло обращение за время текущего такта часов (и, следовательно, все они 
имеют бит К = 1), тогда для удаления случайным образом выбирается одна из них, 
причем желательно чистая, если такая страница существует. 


Алгоритм ѴѴЗСІоск 

Исходный алгоритм «рабочий набор» громоздок, так как при каждом страничном 
прерывании следует проверять таблицу страниц до тех пор, пока не определится 
местоположение подходящего кандидата. Усовершенствованный алгоритм, осно¬ 
ванный на часовом алгоритме, но также использующий информацию рабочего на¬ 
бора, называется \Ѵ5С1оск [54]. Благодаря простоте реализации и хорошей про¬ 
изводительности этот алгоритм широко используется на практике. 

Для него необходима структура данных в виде кольцевого списка страничных 
блоков, как в алгоритме «часы», что изображено на рис. 4.21, а. В исходном поло¬ 
жении этот список пустой. Когда загружается первая страница, она добавляется 
в список. По мере прихода страниц они поступают в список, формируя кольцо. 
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Каждая запись, кроме бита К (показан) и бита М (не показан), содержит поле «вре¬ 
мя последнего использования » из базового алгоритма «рабочий набор». 




Рис. 4.21 . Работа алгоритма ѴѴЗСІоск: пример того, что происходит при бите Я = 1 (а) и (б); 

пример для бита Я = 0 (в) и (г) 


Как и в случае алгоритма «часы», при каждом страничном прерывании первой 
проверяется та страница, на которую указывает стрелка. Если бит К равен 1, это 
значит, что страница использовалась в течение последнего такта часов, поэтому 
она не является идеальным кандидатом на удаление. Тогда бит К устанавливается 
на 0, стрелка передвигается на следующую страницу и для нее повторяется алго¬ 
ритм. Состояние после такой последовательности действий продемонстрировано 
на рис. 4.21, б. 
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Теперь рассмотрим, что происходит, если страница, на которую указывает 
стрелка, имеет бит Я = 0, как показано на рис. 4.21, в. Если возраст страницы боль¬ 
ше величины т и страница — чистая, то она не входит в рабочий набор и на диске 
есть ее действительная копия. Тогда в данный страничный блок просто загружается 
новая страница, как изображено на рис. 4.21, г. Если, напротив, страница «грязная», 
ее нельзя немедленно стереть, так как на диске нет ее последней копии. Чтобы из¬ 
бежать переключения процессов, запись на диск включается в график планирова¬ 
ния, но стрелка сдвигается на позицию, и алгоритм продолжает работу со следую¬ 
щей страницей. ЕІесмотря на то что «грязная» страница может быть старше, чистая 
находится ближе в ряду страниц, которые можно использовать немедленно. 

Теоретически за один обход вокруг циферблата часов для всех страниц может 
оказаться запланированным ввод-вывод с диска. Чтобы уменьшить поток обмена 
с диском, можно установить предел, позволяющий быть записанными максимум 
п страницам. После достижения этой границы новые операции записи перестают 
включаться в график. 

Что происходит, если стрелка обходит целый круг и возвращается к начальной 
точке? Существует два варианта: 

1. Запланирована, по крайней мере, одна операция записи на диск. 

2. ЕІи одной операции записи не запланировано. 

В первом случае стрелка продолжает движение, отыскивая чистую страницу. 
Так как запланирована одна или больше операций записи на диск, со временем 
какая-нибудь из них будет выполнена, и соответствующая страница будет поме¬ 
чена как чистая. Выгружается первая попавшаяся чистая страница. Это не обяза¬ 
тельно та страница, запись которой запланирована первой, потому что драйвер 
диска может изменить порядок работы с диском, чтобы оптимизировать его про¬ 
изводительность. 

Во втором случае все страницы находятся в рабочем наборе, иначе планирова¬ 
лась бы, по крайней мере, одна операция записи. За недостатком дополнительной 
информации проще всего предъявить права на любую чистую страницу и использо¬ 
вать ее. Расположение чистой страницы могло бы отслеживаться во время «чист¬ 
ки». Если в памяти нет чистых страниц, тогда выбирается текущая страница и пере¬ 
писывается на диск. 

Алгоритмы замещения страниц, резюме 

Мы рассмотрели множество различных алгоритмов замещения страниц. В этом 
разделе мы кратко подведем итоги вышесказанного. Список обсужденных алго¬ 
ритмов представлен в табл. 4.2. 

Оптимальный алгоритм заменяет ту страницу, обращение к которой произво¬ 
дилось раньше других, находящихся в данный момент в памяти. К сожалению, не 
существует способа определения того, какая страница будет последней, поэтому 
данный алгоритм не может использоваться на практике. ЕІо он полезен в качестве 
тестовой задачи, относительно которой можно оценивать другие алгоритмы. 

Алгоритм ЫІШ (не использовавшаяся в последнее время страница) делит стра¬ 
ницы на четыре класса в зависимости от состояния битов КиМ. Выбирается любая 
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страница из класса с наименьшим номером. Этот алгоритм легко реализуется, но 
он является очень грубым. Существуют лучшие схемы. 

Таблица 4.2. Алгоритмы замещения страниц, описанные в тексте 

Алгоритм 

Комментарии 

Оптимальный 

Не осуществим, но полезен в качестве тестовой задачи 

ЫВІІ (не использовавшаяся 
в последнее время страница) 

Очень грубый 

РІРО (первым прибыл, первым 
обслужен) 

Может выгрузить важные страницы 

Вторая попытка 

Значительное усовершенствование РІРО 

Часы 

Реалистичный 

ЬРШ (страница, не использовавшаяся 
дольше всего) 

Отличный алгоритм, но его сложно осуществить целиком 

ЫРІІ (редко использовавшаяся 
страница) 

Довольно грубое приближение алгоритма ЬРІІ 

Старение 

Эффективный алгоритм, хорошо аппроксимирующий 
алгоритм ЬРІІ 

Рабочий набор 

Немного дорог для реализации 

ѴѴЗСІоск 

Хороший рациональный алгоритм 


Алгоритм РІРО (первым прибыл — первым обслужен) отслеживает порядок за¬ 
грузки страниц в память, храня их в связном списке. При этом удаление старей¬ 
шей страницы становится тривиальным, но эта страница может использоваться 
в данный момент, поэтому алгоритм РІРО представляет собой плохой выбор. 

Алгоритм «вторая попытка» — это модификация алгоритма РІРО, он перед уда¬ 
лением страницы из памяти проверяет, используется ли она в данный момент. 
Если да, то страница пропускается. Такое изменение сильно повышает произво¬ 
дительность. Алгоритм «часы» представляет собой всего лишь другое осуществ¬ 
ление алгоритма «второй попытки». Он имеет те же самые характеристики произ¬ 
водительности, но требует немного меньше времени на выполнение алгоритма. 

Алгоритм ЫШ (страница, не использовавшаяся дольше всего) — это отличный 
алгоритм, но его нельзя осуществить без специального аппаратного обеспечения. 
Если подобное оборудование недоступно, алгоритм невозможно использовать. 
Алгоритм ЫРІІ (редко использовавшаяся страница) представляет собой грубую 
попытку аппроксимации алгоритма ЫШ. Он не очень хорош. Но существует ал¬ 
горитм «старения», который намного лучше аппроксимирует алгоритм ЫШ и мо¬ 
жет быть эффективно реализован. Это замечательный выбор. 

Последние два алгоритма используют рабочий набор. Алгоритм «рабочий на¬ 
бор» обладает приемлемой производительностью, но дорог в реализации. Алго¬ 
ритм \Ѵ5СІоск — это вариант, который не только дает достойную производитель¬ 
ность, но его также достаточно просто реализовать. 

В итоге двумя наилучшими алгоритмами являются «старение» и\Ѵ5СІоск. Они 
основаны на алгоритме ЫШ и понятии рабочего набора соответственно. Оба обес¬ 
печивают хорошую постраничную подкачку и могут быть реализованы за разум- 
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ную цену. Существует еще несколько алгоритмов, но для практических целей эти 
два являются, вероятно, наиболее важными. 


Моделирование алгоритмов 
замещения страниц 

За годы было проведено несколько работ, посвященных теоретическому модели¬ 
рованию алгоритмов замещения страниц. В данном разделе мы обсудим некото¬ 
рые из этих идей, чтобы увидеть, как работает процесс моделирования. 


Аномалия Билэди 

Интуитивно может показаться, что чем больше страничных блоков имеет память, 
тем меньше будет происходить страничных прерываний. Достаточно удивителен 
тот факт, что это не всегда так. Билэди (Веіасіу) и другие исследователи в своей 
работе [23] описали обнаруженный ими контрпример, в котором алгоритм РІРО 
вызывал больше страничных прерываний при четырех страничных блоках, чем при 
трех. Эта странная ситуация стала известна как аномалия Билэди. Опа проиллюст¬ 
рирована на рис. 4.22 для программы с пятью виртуальными страницами, пронуме¬ 
рованными от 0 до 4. Буквы «Р» показывают, какие обращения вызывают странич¬ 
ные прерывания. Обращения к страницам происходят в следующем порядке: 

012301401234 

На рис. 4.22, а показано, как при наличии трех страничных блоков вызывается 
в целом девять страничных прерываний. На рис. 4.22, б изображены десять странич¬ 
ных прерываний при работе с четырьмя страничными блоками. 
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Рис. 4.22. Аномалия Билэди: алгоритм РІРО при работе с тремя страничными блоками (а); 
алгоритм РІРО при наличии четырех страничных блоков (б) 
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Магазинные алгоритмы 

Аномалия Билэди настолько потрясла многих исследователей в области киберне¬ 
тики, что они начали изучать данную ситуацию, и это привело к развитию целой 
теории алгоритмов подкачки страниц и их свойств. Хотя большая часть данных 
исследований лежит далеко за пределами нашей книги, ниже мы кратко рассмотрим 
основные моменты. За более подробной информацией следует обратиться к [220]. 

Вся работа началась с наблюдения, что каждый процесс с момента запуска фор¬ 
мирует последовательность обращений к памяти. Любая ссылка к памяти соответ¬ 
ствует определенной виртуальной странице. Таким образом, концептуально дос¬ 
туп процесса к памяти можно описать (упорядоченным) списком номеров страниц. 
Этот список называется последовательностью или строкой обращений (геіегепсе 
5ігіп§) и играет главную роль во всей теории. Для простоты далее мы будем рассмат¬ 
ривать вариант машины с одним процессом, то есть когда каждая машина имеет 
единственную определенную последовательность обращений (при нескольких 
процессах мы должны были бы принять во внимание чередование их строк обра¬ 
щений вследствие многозадачности). 

Систему со страничной организацией памяти можно охарактеризовать следу¬ 
ющими тремя объектами: 

1. Последовательность обращений для выполняемого процесса. 

2. Алгоритм замещения страниц. 

3. Количество доступных в памяти страничных блоков т. 

Мысленно мы можем представить себе абстрактный интерпретатор, работаю¬ 
щий следующим образом. Он поддерживает внутренний массив М, отслеживаю¬ 
щий состояние памяти. Количество элементов массива равно количеству вирту¬ 
альных страниц процесса, это число мы назовем п. Массив М разделен на две 
части. В верхней части, куда входит т записей, расположены все страницы, кото¬ 
рые в данный момент находятся в памяти. В нижней части размером п-т записей 
содержатся номера всех страниц, к которым когда-то произошло обращение, но 
они были выгружены из памяти и в данный момент в ней отсутствуют. В исход¬ 
ном положении массив М пуст, так как процесс еще не обращался ни к одной стра¬ 
нице, и в памяти страниц тоже еще нет. 

После запуска процесс начинает вызывать страницы из строки обращений по 
одной. Как только появляется очередная страница, интерпретатор проверяет, на¬ 
ходится ли страница в памяти (то есть в верхней части массива М). Если нет, 
происходит страничное прерывание. Если в памяти есть пустой сегмент (то есть 
верхняя часть массива М содержит меньше, чем т записей), страница загружает¬ 
ся и добавляется в верхнюю часть массива М. Подобная ситуация возникает толь¬ 
ко на начальной стадии выполнения. Если память заполнена (то есть верхняя часть 
массива М содержит т записей), то, чтобы удалить страницу из памяти, активизи¬ 
руется алгоритм замещения страниц. В модели все происходит так: одна страница 
перемещается из верхней части массива М в его нижнюю часть, а требуемая страни¬ 
ца входит наверх. Кроме того, верхняя и нижняя части массива могут быть упоря¬ 
дочены отдельно друг от друга. 
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Чтобы прояснить функционирование интерпретатора, рассмотрим конкретный 
пример, использующий алгоритм замещения страниц ЫШ. Виртуальное адресное 
пространство имеет восемь страниц, а в физической памяти есть четыре странич¬ 
ных блока. Сверху на рис. 4.23 изображена последовательность обращений, состо¬ 
ящая из 24 страниц: 

021354637473355311171341 

Ниже последовательности обращений расположена таблица из 25 столбцов 
и 8 строк. Первый столбец не заполнен, так как он отражает состояние массива М 
до запуска процесса. Каждый следующий столбец демонстрирует массив М по¬ 
сле того, как одна из страниц была извлечена обращением к ней и обработана алго¬ 
ритмом подкачки страниц. Жирный контур отделяет верхнюю часть массива М, 
то есть первые четыре элемента, соответствующие страничным блокам в памяти. 
Страницы внутри жирной рамки находятся в памяти, страницы, расположенные 
ниже, были выгружены на диск. 
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Рис. 4.23. Состояние массива памяти М после обработки каждого элемента строки обращений. 
Последовательность расстояний будет обсуждаться в следующем разделе 


Первой в последовательности обращений является страница 0, поэтому она по¬ 
мещается на самый верх памяти, как показано во втором столбце. Следующая стра¬ 
ница под номером 2 попадает в верхнюю ячейку третьего столбца. Это действие 
сдвигает вниз страницу 0. В данном примере заново загружаемая страница всегда 
занимает верхнюю ячейку, а все остальное по необходимости сдвигается вниз. 

Каждая из первых семи страниц в последовательности обращений вызыва¬ 
ет страничное прерывание. Первые четыре можно обработать, не удаляя страни¬ 
цы из памяти, но начиная со страницы 5 загрузка новой страницы требует удале¬ 
ния старой. 

Второе обращение к странице 3 не вызывает страничного прерывания, потому 
что она уже находится в памяти. Тем не менее интерпретатор убирает ее с того 
места, где она располагалась, и помещает в верхнюю ячейку столбца, как показано 
на рисунке. Процесс продолжает работу некоторое время, до тех пор, пока не 
происходит обращение к странице 5. Эта страница переносится из нижней части 
массива М в верхнюю (то есть она загружается в память с диска). Всякий раз, когда 
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страница, к которой обращается процесс, не находится внутри рамки, очерченной 
жирной линией, происходит страничное прерывание, что отмечено буквами «П» 
в строке под таблицей. 

Теперь кратко перечислим некоторые свойства этой модели. Во-первых, когда 
происходит обращение к странице, она всегда перемещается в верхнюю запись 
массива М. Во-вторых, если запрашиваемая страница уже находилась в массиве М, 
все страницы выше нее сдвигаются на одну позицию вниз. Переход из рамки за ее 
пределы соответствует удалению страниц из памяти. В-третьих, страницы, нахо¬ 
дящиеся ниже объекта обращения, не перемещаются. Таким образом, содержимое 
массива М в точности представляет собой компоненты алгоритма ТІШ. 

Хотя в этом примере используется алгоритм ТІШ, данная модель с тем же успе¬ 
хом работает и с другими схемами. В частности, существует один класс алгорит¬ 
мов, которые представляют особенный интерес, они обладают свойством: 

М{т, г) с М{т + 1, г), 

где число т обозначает количество страничных блоков, а г — это индекс в после¬ 
довательности обращений. Изображенное выше выражение означает, что множе¬ 
ство страниц, после г обращений попавших в верхнюю часть массива М, для памя¬ 
ти, имеющей т страничных блоков, также входит в массив М, если память состоит 
из т + 1 страничных блоков. Другими словами, если мы увеличим размер памяти 
на один страничный блок и выполним процесс заново, то в каждый момент времени 
все страницы, присутствовавшие в памяти во время первой обработки, при втором 
запуске будут также находиться в памяти вместе с еще одной дополнительной 
страницей. 

Если изучить пример на рис. 4.23 и немного подумать о том, как он функцио¬ 
нирует, должно стать ясно, что алгоритм БІШ удовлетворяет данному условию. 
Некоторые другие алгоритмы (например, оптимальный алгоритм замещения) 
также обладают этим свойством, но алгоритм РІРО его не имеет. Алгоритмы, 
удовлетворяющие условию, наложенному на массив М, называются магазинны¬ 
ми алгоритмами (зіаск аІ^огііЬтз). Они не подвержены аномалии Билэди и, соот¬ 
ветственно, намного более любимы теоретиками, занимающимися виртуальной 
памятью. 

Строка расстояний 

Часто для магазинных алгоритмов удобно представить последовательность обра¬ 
щений в более абстрактном виде, чем фактические номера страниц. С этого мо¬ 
мента обращение к странице будет обозначаться с помощью расстояния от верха 
стека, где расположена запрашиваемая страница. Например, обращение к страни¬ 
це 1 в последнем столбце на рис. 4.23 равносильно ссылке на страницу, имеющую 
расстояние 3 от вершины стека (потому что страница 1 перед запросом находилась 
на третьем месте). О страницах, к которым еще не было обращений и поэтому они 
еще не попали в стек памяти (то есть они еще не находятся в массиве М ), говорят, 
что они имеют расстояние °° (бесконечность). Строка расстояний для примера на 
рис. 4.23 изображена внизу рисунка. 




Моделирование алгоритмов замещения страниц 


265 


Заметим, что строка расстояний зависит не только от последовательности об¬ 
ращений, но и от алгоритма подкачки страниц. При одной и той же последователь¬ 
ности обращений различные алгоритмы замещения страниц могут выбирать для 
удаления разные страницы. В результате возникает свой порядок стека для каж¬ 
дого алгоритма. 

Статистические свойства последовательности расстояний сильно влияют на 
производительность алгоритма. На рис. 4.24, а представлена функция, обознача¬ 
ющая плотность вероятности для вхождений страниц в (воображаемую) строку 
расстояний й , Большинство попаданий страниц находится между 1 и к. Если в па¬ 
мяти всего к страничных блоков, то страничные прерывания происходят редко. 



Рис. 4.24. Плотность вероятности для двух гипотетических строк расстояний 

Напротив, на рис. 4.24, б обращения к памяти так разбросаны, что единствен¬ 
ный способ избежать огромного количества страничных прерываний — это предо¬ 
ставить программе столько страничных блоков, сколько она использует виртуаль¬ 
ных страниц. Если вам приходится работать с подобными программами, значит, 
у вас, видимо, просто плохая карма. 


Прогнозирование частоты 
страничных прерываний 

Одно из приятных свойств последовательности расстояний заключается в том, что 
ее можно использовать для прогнозирования количества страничных прерываний, 
которые могут произойти в памяти различного размера. Мы продемонстрируем, 
как можно выполнить подобные вычисления на основе примера с рис. 4.23. Нашей 
целью является следующее; сделать один проход по строке расстояний и по со¬ 
бранной информации суметь предсказать, сколько страничных прерываний мог бы 
вызвать процесс в памяти размером в 1, 2, 3, ..., п страничных блоков, где п — это 
количество виртуальных страниц в адресном пространстве процесса. 

Алгоритм начинается с изучения последовательности расстояний, страница за 
страницей. Он подсчитывает, сколько раз встречается число 1, число 2 и т. д. Пусть 
число г встречается в строке расстояний С, количество раз. Вектор С для последова¬ 
тельности расстояний на рис. 4.23 изображен на рис. 4.25, а. В этом примере полу¬ 
чилось так, что четыре раза происходит обращение к странице, уже находящейся 
на вершине стека. Три раза запрашивается следующая страница и т. д. Пусть С» — 
это количество раз, которое встречается символ °° в последовательности расстояний. 
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Количество раз, 
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Рис. 4.25. Вычисление количества страничных прерываний из последовательности 
расстояний: вектор С (а); вектор Р(б) 

Теперь вычислим вектор Р в соответствии с формулой 

Ё с .+ с -- 

к -т +1 

Величина Р т обозначает количество страничных прерываний, которое про¬ 
изойдет для заданной последовательности расстояний и т страничных блоков. 
На рис. 4.25, б показан вектор Р для строки расстояний, представленной на 
рис. 4.23. Например, величина Р и равная 20, означает, что если память состоит все¬ 
го лишь из одного страничного блока, то из 24-х обращений в последовательности 
вызовут страничное прерывание все, кроме четырех, которые запрашивают ту же 
страницу, что и предыдущая ссылка. 

Чтобы увидеть, как работает формула, вернемся к рамке, очерченной жирной 
линией на рис. 4.23. Пусть т — это количество страниц в верхней части массива М. 
Страничное прерывание происходит всякий раз, когда элемент последовательно¬ 
сти расстояний равен т +1 или больше. В написанной выше формуле суммирует¬ 
ся то количество раз, которое встречаются в последовательности такие элементы. 
Эта модель также может использоваться и для других прогнозов [220]. 


Вопросы разработки систем со страничной 
организацией памяти 

В предыдущих разделах мы объяснили, как работает подкачка по страницам, пред¬ 
ставили несколько основных алгоритмов замещения страниц и показали, как их 
моделировать. Но знания голой механики недостаточно. Чтобы разработать хоро¬ 
шо работающую систему, вы должны знать о ней намного больше. Разница такая 
же, как между человеком, который знает о том, как ходят ладья, конь, слон и другие 
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шахматные фигуры, и хорошим шахматистом. В следующих разделах мы рассмот¬ 
рим другие вопросы, которые должны принимать во внимание разработчики опе¬ 
рационных систем для того, чтобы получить достойную производительность сис¬ 
темы со страничной организацией памяти. 

Политика распределения памяти: 
локальная и глобальная 

В предыдущих разделах мы обсудили несколько алгоритмов, ищущих страницу 
для замещения, когда происходит прерывание. Основной вопрос, связанный с этим 
выбором (который мы тщательно обходили до сих пор): как должна быть распре¬ 
делена память между параллельными конкурирующими работоспособными про¬ 
цессами? 

Обратим внимание на рис. 4.26, а. Здесь три процесса, А, В и С, составляют набор 
работоспособных процессов. Предположим, процесс А вызвал страничное преры¬ 
вание. Должен ли алгоритм замещения страниц пытаться найти наиболее давно 
использовавшуюся страницу, учитывая только шесть страниц, предоставленные в дан¬ 
ный момент процессу А, или же он должен рассматривать все страницы памяти? 
Если алгоритм производит поиск только среди страниц процесса А, наименьший 
возраст имеет страница А 5, и мы получаем ситуацию, изображенную на рис. 4.26, б. 

С другой стороны, если удаляется страница с наименьшим возрастом, незави¬ 
симо от того, к какому процессу она относится, то будет выбрана страница В 3, 
и система попадет в состояние, показанное на рис. 4.26, в. Алгоритм на рис. 4.26, б 
называется локальным, а про схему на рис. 4.26, в говорят, что это глобальный ал¬ 
горитм замещения страниц. Локальные алгоритмы соответствуют размещению 
каждого процесса в фиксированной области памяти. Глобальные алгоритмы дина¬ 
мически распределяют страничные блоки между выполняющимися процессами. 
Таким образом, количество страничных блоков, предоставленных каждому про¬ 
цессу, изменяется со временем. 

В целом глобальные алгоритмы работают лучше, особенно если размер рабоче¬ 
го набора может изменяться за время жизни процесса. Если используется локаль¬ 
ный алгоритм и рабочий набор увеличивается в размере, в результате мы получим 
пробуксовку, даже когда в системе существует достаточное количество свободных 
страничных блоков. Если рабочий набор уменьшается, при локальном алгоритме 
часть памяти потратится впустую. Если же используется глобальный алгоритм, 
система должна непрерывно выносить решения о том, сколько страничных блоков 
нужно предоставить каждому процессу. Можно наблюдать за размером рабочего 
набора с помощью битов возраста страниц, но этот метод не всегда позволяет избе¬ 
жать пробуксовки. Рабочий набор может изменяться в размере за микросекунды, 
тогда как возрастные биты являются грубым усреднением за тик часов. 

Другой способ состоит в том, чтобы иметь в системе алгоритм для распреде¬ 
ления страничных блоков между процессами. Например, можно периодически 
.определять количество работающих процессов и предоставлять каждому равную 
часть памяти. Соответственно, при наличии доступных (то есть не принадлежа- 
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щих операционной системе) 12 416 страничных блоках и 10 процессах каждый 
процесс получит 1241 блок. Оставшиеся 6 блоков поступают в резерв и могут ис¬ 
пользоваться в тот момент, когда происходит страничное прерывание. 
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Рис. 4.26. Локальный алгоритм замещения страниц против глобального: 
исходная конфигурация (а); локальное замещение страниц (б); 
глобальное замещение страниц (в) 


Хотя этот метод кажется справедливым, существует небольшой шанс, что про¬ 
цессы размером 10 Кбайт и 300 Кбайт получат равные области памяти. Вместо это¬ 
го можно предоставлять страницы пропорционально абсолютному размеру каж¬ 
дого процесса, тогда процесс размером 300 Кбайт получит долю памяти в 30 раз 
больше, чем процесс размером 10 Кбайт. При этом разумно отдавать каждому про¬ 
цессу некоторый минимум, чтобы он мог работать независимо от своего размера. 
На некоторых машинах, например, одиночная команда процессора, состоящая из 
двух операндов, может нуждаться в целых шести страницах, потому что сама ко¬ 
манда, операнд-источник и операнд-приемник могут пересекать границы страниц. 
Если предоставить только пять страниц, программа, содержащая подобную инст¬ 
рукцию, вообще не сможет выполняться. 

Если используется глобальный алгоритм, допустимо запускать каждый процесс 
с некоторым количеством страниц, пропорциональным его размеру, но распреде¬ 
ление памяти можно динамически изменять во время работы. Алгоритм РЕЕ (Ра§е 
Еаиіі Егедиепсу — частота страничных прерываний) предоставляет один из спо¬ 
собов управления размещением процессов в памяти. Он говорит, когда увеличи¬ 
вать или уменьшать количество страниц, предоставленных процессу, но не упо¬ 
минает о том, какую страницу замещать по прерыванию. Этот алгоритм только 
контролирует размер набора страниц, назначенных процессу. 

Для большого класса схем замещения страниц, включая алгоритм ІЛШ, извест¬ 
но, что частота прерываний уменьшается при увеличении числа предоставленных 
страниц, как мы обсуждали выше. Эта посылка лежит в основе алгоритма РЕЕ. 
Данное свойство иллюстрирует рис. 4.27. 
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Количество предоставленных страничных блоков 

Рис. 4.27. Частота страничных прерываний как функция от количества 
предоставленных процессу страничных блоков 

Частота страничных прерываний измеряется напрямую: просто считается ко¬ 
личество прерываний в секунду, возможно также с вычислением скользящего 
среднего за несколько последних секунд. Существуют достаточно легкие способы 
такого подсчета, например, к текущему среднему значению прибавляется значе¬ 
ние в секундах в данный момент и делится на два. Пунктирная линия, обозначен¬ 
ная буквой А, соответствует частоте страничных прерываний, выше которой она 
недопустимо высока, поэтому увеличивается количество страничных блоков, пре¬ 
доставленных прерванному процессу, с целью уменьшения процента прерываний. 
Пунктирная линия В соответствует очень низкой частоте страничных прерываний, 
позволяющей сделать вывод, что процесс занимает слишком много памяти. В этом 
случае у него можно забрать несколько страничных блоков. Таким образом, 
алгоритм РРР пытается сохранить частоту подкачки страниц для каждого процес¬ 
са внутри допустимых границ. 

Важно отметить, что некоторые алгоритмы замещения страниц могут работать 
как с локальной политикой замещения страниц, так и с глобальной. Например, 
алгоритм РІРО может выгрузить самую старую страницу во всей памяти (глобаль¬ 
ный алгоритм) или старейшую страницу, принадлежащую данному процессу (локаль¬ 
ный алгоритм). Аналогично, алгоритм ЬІШ или некоторые его аппроксимации 
могут заменить страницу, не использовавшуюся дольше всего, выбираемую из всей 
памяти (глобальный алгоритм) или выбираемую среди страниц, соответствующих 
выполняемому в текущий момент процессу (локальный алгоритм). Выбор между 
локальной и глобальной политикой в некоторых случаях не зависит от алгоритма. 

С другой стороны, для некоторых алгоритмов замещения страниц имеет смысл 
только локальная стратегия. В частности, алгоритмы «рабочий набор» и \ѴЗС1оск 
относятся іс конкретному процессу и должны применяться именно в этом контек¬ 
сте. Реально для машины в целом не существует понятия рабочего набора, и если 
попытаться использовать объединение всех рабочих наборов, то это непременно 
приведет к потере характерных свойств и хорошо работать не будет. 

Регулирование загрузки 

Даже при работе с лучшим алгоритмом замещения страниц и оптимальным глобаль¬ 
ным распределением страничных блоков между процессами может произойти так, 
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что система начнет буксовать. В самом деле, когда сумма рабочих наборов всех 
процессов превышает размеры памяти, можно ожидать пробуксовки. Симптомом 
этой ситуации является показание алгоритма РЕЕ, что некоторые процессы нуж¬ 
даются в дополнительной памяти, но в системе нет процессов, требующих меньше 
памяти. В таком случае не существует способа предоставить больше памяти тем 
процессам, которым это необходимо, без повреждения каких-то других процессов. 
Есть только одно реальное решение: временно избавиться от некоторых процессов. 

Уменьшить количество конкурирующих за использование памяти процессов 
можно, выгрузив некоторые из них целиком на диск и освободив все занимаемые 
ими страницы. Например, один процесс можно полностью переместить на диск, а его 
страничные блоки разделить между буксующими процессами. Если пробуксовка 
прекращается, то система может работать некоторое время в таком состоянии. Если 
не прекращается, то выгружается следующий процесс и т. д. до тех пор, пока не 
закончится пробуксовка. Таким образом, даже при страничной организации памяти 
и страничной подкачке все еще необходима обычная подкачка (свопинг), только те¬ 
перь она используется для того, чтобы уменьшить потенциальную потребность в па¬ 
мяти, а не с целью возврата блоков в систему для непосредственного использования. 

Обычная подкачка процессов для того, чтобы ослабить загрузку памяти, напо¬ 
минает двухуровневое планирование, при котором часть процессов помещается на 
диск и используется временный планировщик для составления графика работы 
оставшихся процессов. Понятно, что две идеи можно комбинировать, то есть вы¬ 
грузить достаточное количество процессов на диск, чтобы сделать приемлемой ча¬ 
стоту страничных прерываний. Периодически некоторые процессы подкачивают¬ 
ся с диска, и тогда туда целиком выгружаются другие процессы. 

Еще одним фактором, который следует принять во внимание, является степень 
многозадачности. Как мы видели на рис. 4.4, когда количество процессов в основ¬ 
ной памяти слишком мало, центральный процессор может простаивать значитель¬ 
ные периоды времени. Когда нужно принять решение о том, какой процесс выгру¬ 
жать из памяти, это наблюдение является аргументом в пользу учета не только 
размера процесса и частоты подкачки страниц. Оно важно и для определения того, 
является ли он процессом, ограниченным возможностями процессора, или процес¬ 
сом, ограниченным скоростью ввода-вывода, а также аналогичных свойств осталь¬ 
ных процессов. 

Размер страницы 

Зачастую размер страницы является параметром, выбираемым операционной си¬ 
стемой. Даже если аппаратное обеспечение предусматривает, например, размер 
страницы 512 байт, операционная система может просто рассматривать страни¬ 
цы 0 и 1, 2 и 3, 4 и 5 и т. д. как страницы размером 1 Кбайт, всегда предоставляя 
для них два последовательных страничных блока. 

Определение наилучшего размера страниц требует уравновешивания несколь¬ 
ких параллельных факторов. Поэтому не существует абсолютного оптимального 
решения. Прежде всего, возникают два довода в пользу маленького размера стра¬ 
ниц. Случайно выбранный текст, данные или сегмент стека не заполняют целое 
количество страниц. В среднем половина последней страницы оказывается пустой, 
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и это дополнительное пространство пропадает. Такие потери называют внутрен¬ 
ней фрагментацией. Если в памяти п сегментов, а размер страницы равен р байтам, 
пр /2 байт будет потрачено впустую в результате внутренней фрагментации. Это 
разумный аргумент в пользу страниц небольшого размера. 

Другой довод становится очевидным, если мы представим себе программу, со¬ 
стоящую из восьми последовательных этапов, по 4 Кбайт каждый. При размере 
страницы 32 Кбайт программе должно быть постоянно выделено 32 Кбайт. При 
размере страницы 16 Кбайт ей необходимо только 16 Кбайт. При размере страни¬ 
цы 4 Кбайт или меньше программа требует всего лишь 4 Кбайт к любой момент 
времени. То есть большой размер страницы скорее, чем маленький, станет причи¬ 
ной того, что в памяти находится неиспользуемая часть страницы. 

С другой стороны, небольшой размер страницы означает, что программам бу¬ 
дет нужно много страниц, следовательно, огромная таблица страниц. Программа 
размером 32 Кбайт требует всего четыре страницы по 8 Кбайт и 64 страницы по 
512 байт. Как правило, страница за раз переносится на диск и с него, при этом боль¬ 
шая часть времени уходит на поиск цилиндра и задержку вращения, так что переме¬ 
щение маленькой страницы занимает почти столько же времени, сколько и большой. 
Может потребоваться 64 х 10 мс, чтобы загрузить 64 страницы размером 512 байт, 
и всего лишь 4 х 12 мс для загрузки четырех страниц по 8 Кбайт. 

На некоторых машинах таблица страниц должна записываться в аппаратные 
регистры каждый раз, когда процессор переключается от одного процесса к друго¬ 
му. Если на таком компьютере страница имеет маленький размер, то время, требу¬ 
ющееся для загрузки таблицы, будет увеличиваться пропорционально уменьше¬ 
нию размера страницы. Более того, пространство, занятое таблицей страниц, также 
возрастает с уменьшением страницы. 

Этот последний момент можно проанализировать математически. Пусть сред¬ 
ний размер процесса равен з байт, а страницы — р байт. Кроме того, предположим, 
что запись для каждой страницы требует е байт. Тогда приблизительное количество 
страниц, необходимое для процесса, равно з/р, что займет зе/р байт для таблицы 
страниц. Потеря памяти в последней странице процесса вследствие внутренней 
фрагментации равна р/2. Таким образом, общие накладные расходы вследствие 
поддержки таблицы страниц и потери от внутренней фрагментации равны сумме 
этих двух составляющих: 

расход = зе/р + р/2. 

Первое слагаемое (размер таблицы страниц) увеличивается при уменьшении 
размера страницы. Второе слагаемое (внутренняя фрагментация) при увеличении 
размера страницы возрастает. Оптимальный вариант должен находиться где-то 
посередине. Если взять первую производную по переменной р и приравнять ее к 
нулю, мы получим равенство: 

- зе/р 2 + 1/2 = 0. 

Из этого равенства мы можем получить формулу, дающую оптимальный размер 
страниц (принимая во внимание только потери памяти на фрагментацию и раз¬ 
мер таблицы страниц). В результате получится: 
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Для среднего размера процесса 5=1 Мбайт и размера записи в таблице страниц 
е = 8 байт оптимальный размер страницы будет равен 4 Кбайт. В серийно выпус¬ 
каемых компьютерах использовался размер страниц в диапазоне от 512 байт до 
64 Кбайт. Раньше обычно употреблялась величина 1 Кбайт, но в наши дни более 
часто встречаются 4 Кбайт или 8 Кбайт. Так как памяти становится больше, то раз¬ 
мер страниц также имеет тенденцию роста (но зависимость не линейная). Увели¬ 
чение вчетверо размера оперативной памяти редко удваивает размер страницы. 


Отдельные пространства команд и данных 

Большинство компьютеров имеют единое адресное пространство, в котором содер¬ 
жатся и программы, и данные к ним, как показано на рис. 4.28, а. Если адресное 
пространство достаточно вместительно, все прекрасно работает. Но часто адрес¬ 
ное пространство имеет слишком маленький размер, что вынуждает программис¬ 
тов ломать головы над тем, как разместить в нем все необходимое. 


Единое 

адресное пространство Б пространство 


Данные 


Программа 



Программа 



} Не использованные 
страницы 


Данные 


Рис. 4.28. Одно адресное пространство (а); отдельные I и й пространства (б) 

Одно из решений проблемы, впервые примененное на (16-разрядном) компью¬ 
тере РОР-11, заключается в разделении адресных пространств для инструкций 
(или команд, то есть текста программы) и данных. Они называются І-простран- 
ство (іпЫшсСіоп — инструкция) и О-пространство (сіаСа — данные). Каждое адрес¬ 
ное пространство расположено в диапазоне от 0 и до некоторого максимума, обычно 
до 2 1б -1 или 2 32 -1. На рис. 4.28,6 изображены оба пространства. Компоновщик 
должен знать, когда используются отдельные I- и Б-пространства, потому что если 
они существуют, адреса данных настраиваются на виртуальный адрес 0 вместо того, 
чтобы начинаться после программы. 

В компьютере, устроенном таким образом, оба адресных пространства могут 
иметь страничную организацию независимо друг от друга. Каждое из них облада¬ 
ет своей собственной таблицей страниц и собственным отображением виртуаль¬ 
ных страниц на физические страничные блоки. Когда аппаратура хочет выбрать 
команду, она знает, что должна использовать І-пространство и таблицу страниц 
І-пространства. Аналогично, обращения к данным должно происходить через 
таблицу страниц О-пространства. Кроме этого различия, поддержка отдельных 
I- и О-пространств не вносит каких-либо специальных осложнений и удваивает 
доступное адресное пространство. 
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Совместно используемые страницы 

Еще один вопрос разработки — это совместный доступ или разделение страниц. 
В больших многозадачных системах часто случается, что в одно и то же время 
несколько пользователей работают с одной программой. Ясно, что более эффек¬ 
тивно использовать страницы совместно, чтобы избежать одновременного при¬ 
сутствия в памяти двух копий одной и той же страницы. К сожалению, не все 
страницы разделяемы. В частности, страницы только для чтения, такие как текст 
программы, можно использовать совместно, а страницы с данными — нельзя. 

Если поддерживаются отдельные I- и Б-пространства, относительно просто 
обеспечить общий доступ к программам, разрешив двум или более процессам ис¬ 
пользовать одну и ту же таблицу страниц для их І-пространства и различные таб¬ 
лицы страниц для их Б-пространств. Обычно при такой реализации поддержки 
совместного доступа таблицы страниц и структуры данных не зависят от таблицы 
процесса. Тогда каждый процесс в своей таблице процесса имеет два указателя: 
один на таблицу страниц І-пространства и другой на таблицу страниц Б-простран- 
ства, как показано на рис. 4.29. Когда планировщик выбирает процесс для запу¬ 
ска, он использует эти указатели, чтобы определить местоположение соответству¬ 
ющих таблиц страниц, и настраивает диспетчер памяти (ММБ), использующий 
их. Даже если отсутствуют отдельные I- и Б-пространства, процессы могут разде¬ 
лять программы (или, что иногда случается, библиотеки), но механизм совмест¬ 
ного доступа усложняется. 



Программа Данные-1 

I._„ ,_ 

V 

Таблицы страниц 


Данные-2 
_ ) 


Рис. 4.29. Две процесса используют совместно одну и ту же программу, 
разделяя ее таблицу страниц 


Когда два или более процессов совместно используют один программный код, 
возникает проблема разделения страниц. Предположим, что процессы Л и В пред¬ 
ставляют собой дважды запущенный текстовый редактор и вместе используют его 
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страницы. Если планировщик решает удалить процесс А из памяти, выгрузка всех 
его страниц и заполнение пустых страничных блоков какой-либо другой про¬ 
граммой приведет к тому, что процесс В вызовет массу страничных прерываний, 
чтобы вернуть назад эти страницы. 

Когда процесс А завершает свою работу, очень важно знать, что страницы до 
сих пор используются, чтобы их дисковое пространство случайно не оказалось ос¬ 
вобожденным. Поиск во всех таблицах страниц с целью проверки совместного ис¬ 
пользования страниц обычно слишком дорог, поэтому необходимы специальные 
структуры данных для отслеживания разделенных страниц, особенно если едини¬ 
цей совместного доступа является отдельная страница (или серия страниц), а не 
целая таблица страниц. 

Совместное использование данных более сложно, чем совместное использование 
кода программы, но и оно возможно. В частности, в системе ТЖІХ после системно¬ 
го вызова Гогк родительский и дочерний процессы обязаны совместно использо¬ 
вать и текст программы, и данные. В системах со страничной организацией памя¬ 
ти часто делается так: каждому из этих процессов дается своя собственная таблица 
страниц, но в них есть указатель на один и тот же набор страниц. Таким образом, 
не выполняется копирование страниц при вызове Гогк. Однако все страницы дан¬ 
ных для обоих процессов отображаются как КЕАЭ ОКЬѴ (только для чтения). 

Пока оба процесса только читают свои данные, не модифицируя их, это состоя¬ 
ние может не изменяться. Как только один из двух процессов обновляет слово в па¬ 
мяти, нарушение защиты «только для чтения» вызывает прерывание, передающее 
управление операционной системе. При этом создается копия страницы, и теперь 
каждый процесс имеет свой собственный персональный экземпляр страницы. Для 
обеих копий разрешается и чтение, и запись, поэтому последующие записи в любую 
из двух страниц происходят без прерываний. В результате работы такой системы 
те страницы, которые никогда не модифицируются (включая все страницы с тек¬ 
стом программы), не должны копироваться. Необходимо дублировать только стра¬ 
ницы, содержащие фактически изменяемые данные. Такой подход, называемый 
копированием при записи, повышает производительность путем уменьшения ко¬ 
личества операций дублирования. 

Политика очистки страниц 

Подкачка страниц работает лучше, когда в системе существует достаточное коли¬ 
чество свободных страничных блоков, которые можно затребовать при странич¬ 
ном прерывании. Если все страничные блоки заполнены и, более того, изменялись, 
перед загрузкой новой страницы сначала нужно записать старую на диск. Чтобы 
обеспечить обильный запас свободных блоков, во многих системах со странич¬ 
ной организацией памяти работает фоновый процесс, называемый страничным 
демоном, который большую часть времени спит, но периодически просыпается 
и проверяет состояние памяти. Если свободно слишком мало блоков, страничный 
демон начинает выбирать страницы для удаления их из памяти, используя опре¬ 
деленный алгоритм замещения. Если эти страницы изменялись со времени загруз¬ 
ки, они записываются на диск. 
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Так или иначе, запоминается прежнее содержимое страницы. В случае если 
одна из выгруженных страниц требуется снова еще до того, как ее блок был пере¬ 
записан, ее можно вернуть назад, удалив из пула свободных страничных блоков. 
Сохранение запаса страничных блоков в результате дает лучшую производитель¬ 
ность, чем использование всей памяти и затем поиск блока в тот момент, когда он 
запрашивается. По крайней мере, страничный демон гарантирует, что все свобод¬ 
ные блоки являются чистыми, значит, когда они требуются, их не нужно спешно 
записывать на диск. 

Осуществить эту стратегию очистки страниц можно, например, с помощью ча¬ 
сов с двумя стрелками. Передняя (длинная) стрелка контролируется страничным 
демоном. Когда она указывает на «грязную» страницу, копия страницы на диске 
обновляется, а стрелка сдвигается на позицию. Когда она направлена на чистую 
страницу, она просто сдвигается вперед. Задняя (короткая) стрелка используется 
для замещения страниц, как в стандартном алгоритме «часы». Только теперь воз¬ 
растает вероятность попадания короткой стрелки на чистую страницу благодаря 
работе страничного демона. 

Интерфейс виртуальной памяти 

До сих пор в наших рассуждениях предполагалось, что виртуальная память про¬ 
зрачна для процессов и программистов, то есть все, что они видят — это огромное 
виртуальное адресное пространство на компьютере с небольшой (или меньшей) 
физической памятью. Обычно это так и происходит, но в некоторых прогрессивных 
системах программистам предоставлен определенный контроль над картой памя¬ 
ти, который они могут использовать для улучшения поведения программы нетра¬ 
диционными способами. В этом разделе мы кратко рассмотрим некоторые из них. 

Одной из причин предоставления программистам контроля над картой памяти 
является желание позволить двум и более процессам совместно использовать одну 
и ту же память. Если программисты сами будут давать названия областям памяти, 
один процесс сможет дать другому процессу имя области памяти, так что этот 
второй процесс также сможет ей пользоваться. Если два (или больше) процессов 
разделяют страницы памяти, становится реальной высокая пропускная способ¬ 
ность совместного доступа — один процесс пишет в разделяемую память, а другой 
читает из нее. 

Совместное использование страниц может также использоваться для реализа¬ 
ции высокопроизводительных систем передачи сообщений. Когда передается со¬ 
общение, данные обычно копируются из одного адресного пространства в другое, 
что имеет значительную стоимость. Если процессы могут управлять своей картой 
страниц, можно передавать сообщения с помощью посылающего процесса, убира¬ 
ющего из карты страницу (страницы), содержащую сообщение, и принимающего 
процесса, вносящего ее (их) в карту. При этом должны копироваться только име¬ 
на страниц вместо всех данных. 

Еще одна современная техника управления памятью носит название распре¬ 
деленной памяти совместного доступа [114, 204, 205, 369]. Она основана на том, 
чтобы позволить нескольким процессам в сети совместно использовать набор 
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страниц, возможно (но не обязательно) как единственное разделяемое линейное 
адресное пространство. Когда процесс обращается к странице, не отображаемой 
в данный момент, он вызывает страничное прерывание. Обработчик страничных 
прерываний, который может находиться в ядре или в пользовательском простран¬ 
стве, определяет машину, содержащую страницу, и посылает ей сообщение с просьбой 
выгрузить страницу и послать ее по сети. Когда страница прибывает, она попадает 
в карту и прерванная команда перезапускается. Мы будем более детально изучать 
распределенную память с совместным доступом в главе 8. 


Вопросы реализации 

Разработчики систем виртуальной памяти должны сделать выбор между основ¬ 
ными теоретическими алгоритмами: «вторая попытка» или «старение», локальное 
распределение страниц или глобальное, предоставление страниц по запросу или 
опережающая подкачка страниц. Но они также должны быть осведомлены о ко¬ 
личестве проблем, возникающих при практической реализации каждого вариан¬ 
та. В этом разделе мы рассмотрим несколько наиболее общих вопросов и некото¬ 
рые из их решений. 

Участие операционной системы в процессе 
подкачки страниц 

Можно выделить четыре ситуации, в которых операционной системе приходится 
выполнять работу, относящуюся к страничной подкачке: создание процесса, вы¬ 
полнение процесса, страничное прерывание и завершение процесса. Сейчас мы 
кратко рассмотрим каждую из этих ситуаций по очереди, чтобы понять, что долж¬ 
но быть сделано в каждом случае. 

При создании нового процесса в системе со страничной организацией памя¬ 
ти операционная система должна определить, насколько будут велики программа 
и данные к ней (в исходном состоянии), и создать для них таблицу страниц. Для 
таблицы страниц должно быть предоставлено пространство в памяти, и ее нужно 
проиницнализировать. Таблица страниц не обязана быть резидентной в то время, 
когда процесс выгружается на диск, но она должна быть в памяти, пока про¬ 
цесс работает. Кроме того, в области подкачки на диске должно быть выделено 
пространство, чтобы в момент выгрузки страницы на диск было бы место, куда 
ее можно поместить. Область подкачки также нужно инициализировать текстом 
программы и данными, чтобы, когда новый процесс запустится, вызывая стра¬ 
ничные прерывания, страницы можно было подгрузить с диска. Некоторые си¬ 
стемы подкачивают страницы текста программы прямо из исполняемого файла, 
таким образом, экономя время инициализации и место на диске. Наконец, ин¬ 
формация о таблице страниц и области подкачки на диске должна быть записана 
в таблицу процесса. 

Когда процесс планируется для исполнения, для нового процесса требуется 
сброс диспетчера памяти (ММИ), а содержимое буфера быстрого преобразования 
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адреса (ТЬВ) должно быть очищено, чтобы избавиться от следов предыдущего 
процесса. Таблицу страниц нового процесса нужно сделать текущей, обычно это 
производится путем копирования ее или указателя на нее в некоторый аппарат¬ 
ный регистр (регистры). Часть страниц процесса или они все могут быть считаны 
в память, чтобы уменьшить изначальное количество страничных прерываний. 

Когда происходит страничное прерывание, операционная система должна про¬ 
читать аппаратные регистры, чтобы определить, какой виртуальный адрес вызвал 
ошибку. Из полученной информации она должна вычислить, какая требуется стра¬ 
ница, и определить ее местоположение на диске. Затем операционной системе нуж¬ 
но найти доступный страничный блок для размещения новой страницы, при необ¬ 
ходимости она выгружает какую-либо старую страницу. После этого операционная 
система должна считать требуемую страницу в страничный блок. И наконец, она 
должна вернуть в предыдущее состояние счетчик команд, чтобы тот указывал на 
вызвавшую прерывание инструкцию, и запустить эту команду заново. 

Когда процесс завершается, операционная система должна освободить его таб¬ 
лицу страниц, его страницы и дисковое пространство, которое занимают страни¬ 
цы, когда они находятся на диске. Если некоторые из страниц разделяются между 
несколькими процессами, страницы в памяти и на диске могут быть освобождены 
только тогда, когда окончит работу последний использующий их процесс. 

Обработка страничного прерывания 

Наконец мы подошли к моменту, когда можно более детально описать, что же про¬ 
исходит при страничном прерывании. Последовательность действий следующая: 

1. Аппаратное обеспечение переключает систему в режим ядра, сохраняя 
счетчик команд в стеке. На большинстве машин в специальных регистрах 
процессора сохраняется некоторая информация о состоянии текущей ин¬ 
струкции. 

2. Запускается написанная на ассемблере программа, сохраняющая основные 
регистры и другую изменяющуюся информацию, защищая ее от разруше¬ 
ния операционной системой. Эта программа вызывает операционную сис¬ 
тему как процедуру. 

3. Операционная система обнаруживает, что произошло страничное прерыва¬ 
ние, и пытается найти необходимую виртуальную страницу. Часто требу¬ 
емую информацию содержит один из аппаратных регистров. Если нет, 
операционная система должна достать из стека счетчик команд, выбрать ин¬ 
струкцию и программно проанализировать ее, чтобы определить, что она 
делала в тот момент, когда случилась ошибка. 

4. Как только становится известен виртуальный адрес, вызвавший прерыва¬ 
ние, система проверяет, имеет ли силу этот адрес и согласуется ли защита с 
доступом. Если нет, то процессу посылается сигнал или процесс уничтожа¬ 
ется. Если адрес действителен и не произошло ошибки защиты, система про¬ 
веряет наличие свободных страничных блоков. Если свободных блоков нет, 
запускается алгоритм замещения страниц, выбирающий жертву. 
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5. Если выбранный страничный блок «грязный», страница заносится в график 
записи на диск и происходит переключение контекста, приостанавлива¬ 
ющее вызвавший прерывание процесс и позволяющее работать другому 
процессу до тех пор, пока не будет выполнен перенос страницы на диск. 
В любом случае блок отмечается как занятый, чтобы предотвратить его ис¬ 
пользование в других целях. 

6. Как только страничный блок очищается (или немедленно, или после запи¬ 
си на диск), операционная система ищет адрес на диске, где находится тре¬ 
буемая страница, и планирует дисковую операцию для ее переноса в память. 
Во время загрузки страницы процесс, вызвавший прерывание, все еще при¬ 
остановлен и выполняется другой пользовательский процесс, если такой 
доступен. 

7. Когда дисковое прерывание отмечает, что страница поступила в память, об¬ 
новляется таблица страниц, отражая ее позицию, а блок помечается, как на¬ 
ходящийся в нормальном состоянии. 

8. Прерванная команда возвращается к тому состоянию, с которого она начи¬ 
налась, и значение счетчика команд приостановленного процесса (в стеке 
или в системной ячейке памяти) корректируется так, чтобы указывать на 
эту команду. 

9. Прерванный процесс вносится в график, и операционная система возвраща¬ 
ет управление ассемблерной процедуре, вызывавшей ее. 

10. Эта процедура перезагружает регистры и другую информацию о состоянии 
и возвращает управление в пользовательское пространство для продолже¬ 
ния выполнения пользовательской программы, как если бы никакого пре¬ 
рывания не происходило. 


Перезапуск прерванной команды процессора 

Когда программа обращается к странице, которой нет в памяти, команда процес¬ 
сора, вызвавшая прерывание, останавливается на полпути, и происходит преры¬ 
вание с передачей управления операционной системе. После того как операцион¬ 
ная система перенесла в память необходимую страницу, она должна перезапустить 
команду, вызвавшую прерывание. Это проще сказать, чем сделать. 

Чтобы увидеть суть данной проблемы в черном цвете, рассмотрим центральный 
процессор, в который поступила команда с двумя адресами, например процессор 
Моіогоіа 680x0, широко используемый во встроенных системах. Команда 

МОѴЕЛ #6(А1) ,2(А0) 

занимает 6 байт (рис. 4.30). Для того чтобы перезапустить ее, операционная систе¬ 
ма должна определить, где находится первый байт команды. Значение счетчика 
команд во время прерывания зависит от того, какой операнд вызвал ошибку, и от 
реализации микрокода процессора. 

На рис. 4.30 у нас есть команда, начинающаяся с адреса 1000, которая совер¬ 
шает три обращения к памяти: само слово команды и два сдвига для операндов. 
В зависимости от того, какое из этих трех обращений к памяти вызывает странич- 




Вопросы реализации 


279 


ное прерывание, счетчик команд может принять значение 1000, 1002 или 1004 во 
время прерывания. Зачастую операционная система не в силах однозначно опре¬ 
делить, где начиналась команда. Если в момент прерывания счетчик команд равен 
1002, у операционной системы нет способа определить, является ли слово по адре¬ 
су 1002 адресом памяти, связанным с командой по адресу 1000 (то есть операн¬ 
дом) или кодом операции самой команды. 


МОѴЕ.І_#6(А1), 2(А0) 

|<-16 бит-Н 

} Код операции 
} Первый операнд 
} Второй операнд 

Рис. 4.30. Команда, вызвавшая страничное прерывание 
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Какой бы неприятной ни была данная проблема, могло бы быть гораздо хуже. 
У процессора 680x0 есть очень удобные для программистов автоинкрементные 
режимы адресации, а это означает, что побочным эффектом выполнения команды 
является увеличение (или уменьшение) одного или двух регистров. Инструкции, 
использующие автоинкрементный режим, также могут прерываться. В зависимо¬ 
сти от деталей микропрограммы приращение может быть сделано до обращения к 
памяти, и в этом случае операционная система должна уменьшить регистр про¬ 
граммно перед тем, как запустить команду заново. Автоматическое приращение 
может выполняться и после обращения к памяти, в этом случае оно еще не было 
сделано в момент прерывания и не должно отменяться операционной системой. 
Также существует режим автоматического уменьшения на единицу, и он вызыва¬ 
ет ту же самую проблему. Точные детали того, выполнялось автоувеличение или 
автоуменьшение регистра до или после обращений к памяти, могут различаться 
для разных команд и для различных моделей процессоров. 

К счастью, на некоторых машинах разработчики центральных процессоров пре¬ 
дусматривают решение этой проблемы обычно в форме скрытых внутренних ре¬ 
гистров, в которые копируется счетчик команд перед выполнением каждой инст¬ 
рукции. Такие машины также могут иметь второй регистр, говорящий о том, какой 
из регистров и на сколько уже был увеличен или уменьшен. Обладая этой информа¬ 
цией, операционная система в силах однозначно отменить все эффекты прерванной 
инструкции, так что потом ее можно целиком запустить заново. Если эта инфор¬ 
мация недоступна, операционной системе придется покрутиться, чтобы понять, 
что же случилось и как это исправить. Видимо, разработчики аппаратуры не смог¬ 
ли решить эту проблему, поэтому они опустили руки и предоставили возможность 
разбираться с этим разработчикам операционных систем. Славные парни. 


Блокирование страниц в памяти 

Хотя в этой главе мы практически не вспоминали о вводе-выводе, тот факт, что 
компьютер имеет виртуальную память, вовсе не означает, что ввод-вывод отсутству¬ 
ет. Виртуальная память и ввод-вывод незаметно взаимодействуют друг с другом. 
Рассмотрим процесс, который только что сделал системный вызов, чтобы считать 
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информацию из некоторого файла или устройства в буфер внутри своего адресно¬ 
го пространства. Пока процесс ожидает завершения операции ввода-вывода, он 
приостанавливается, предоставляя возможность работы другому процессу. Этот 
другой процесс вызывает страничное прерывание. 

Если алгоритм подкачки страниц — глобальный, существует маленький, но не 
равный нулю шанс, что страница, содержащая буфер ввода-вывода, будет выбрана 
для удаления из памяти. Если устройство ввода-вывода в данный момент находит¬ 
ся в процессе выполнения прямой передачи данных в эту страницу, ее удаление 
станет причиной записи части данных в буфер, которому они принадлежат, а часть 
данных запишется в заново загруженную страницу. Одно решение этой проблемы 
заключается в том, чтобы блокировать страницы, занятые вводом-выводом, так 
чтобы они не удалялись из памяти. Блокирование страницы часто называется при¬ 
шпиливанием (ріпшп§) ее в памяти. Другое решение — это сначала выполнить весь 
ввод-вывод в буферы ядра, а затем копировать данные в пользовательские стра¬ 
ницы. 

Хранение страничной памяти на диске 

В ходе рассмотрения алгоритмов замещения страниц мы видели, как выбирается 
страница для удаления. Мы почти ничего не сказали о том, в какое место на диске 
она помещается после выгрузки из памяти. Теперь настало время описать некото¬ 
рые из проблем, связанных с управлением дисками. 

Простейший алгоритм для распределения страничного пространства на диске 
заключается в поддержке специальной области подкачки (свопинга) на диске. При 
загрузке системы эта область является пустой и представляется в памяти единой 
записью, имеющей свой начальный адрес и размер. Когда запускается первый про¬ 
цесс, резервируется участок области подкачки размером с этот процесс, а осталь¬ 
ная область уменьшается ровно на это количество. Как только запускаются новые 
процессы, им предоставляются участки области подкачки, равные по размеру их 
образам памяти. Как только они завершаются, их дисковое пространство освобож¬ 
дается. Область подкачки управляется как список свободных участков. 

С каждым процессом связывается адрес его области подкачки на диске, кото¬ 
рый хранится в таблице процесса. Вычисление адреса для записи страницы стано¬ 
вится простым: всего лишь прибавляется смещение страницы внутри виртуаль¬ 
ного адресного пространства к адресу начала области подкачки. Однако перед тем, 
как процесс может начать работу, область подкачки должна быть инициализиро¬ 
вана. Это можно сделать, копируя полный образ процесса в область подкачки так, 
чтобы его по необходимости можно было переносить в память. Второй способ: 
загрузить весь процесс в память и позволить ему постранично выгружаться на 
диск, также когда это требуется. 

Но в такой простой модели есть одна проблема: процессы могут увеличиваться 
в размере после запуска. Хотя текст программы обычно фиксирован, иногда мо¬ 
жет расти область данных и всегда может увеличиваться стек. Следовательно, 
стратегия, заключающаяся в резервировании отдельных областей подкачки для 
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текста, данных и стека и позволении каждой из этих областей состоять более чем 
из одного участка на диске, может оказаться более удачной. 

Другая крайность состоит в том, чтобы, наоборот, ничего не размещать заранее; 
предоставлять пространство на диске для каждой страницы, когда она выгружается 
на диск, и освобождать это место, когда она подкачивается обратно в память. При 
таком подходе процессы в памяти не привязаны к какому-либо пространству 
подкачки на диске. Его недостаток состоит в том, что адрес на диске, необходимый 
в памяти, отслеживается для каждой страницы на диске. Другими словами, для 
каждого процесса должна поддерживаться таблица, содержащая местоположение 
каждой страницы на диске. Эти два альтернативных варианта показаны на рис. 4.31. 

Диск Диск 




Рис. 4.31 . Постраничная подкачка в статическую область свопинга (а); 
динамическое резервирование страниц(б) 

На рис. 4.31, а продемонстрирована таблица страниц с восемью страницами. 
Страницы 0, 3, 4 и 6 находятся в оперативной памяти. Страницы 1, 2, 5 и 7 хра¬ 
нятся на диске. Область подкачки на диске равна по размеру виртуальному адрес¬ 
ному пространству процесса (восемь страниц), причем у каждой страницы есть 
фиксированное место, куда она записывается при удалении из оперативной памя¬ 
ти. Вычисление ее адреса требует информации только о том, где начинается об¬ 
ласть страничной подкачки процесса на диске, так как страницы хранятся в ней 
последовательно в порядке своих виртуальных номеров. Страницы, находящиеся 
в памяти, всегда имеют дубликат на диске, но эта копия может быть устаревшей, 
если страница была изменена с момента загрузки в память. 

На рис. 4.31, б страницы не имеют фиксированных адресов на диске. Когда 
страница выгружается из памяти, на ходу выбирается пустая страница на диске, 
и соответственно обновляется карта диска (с ячейками для каждого дискового 
адреса, соответствующего одной виртуальной странице). У страниц, находящихся 
в памяти, нет копий на диске. Их записи в карте диска содержат ошибочный дис¬ 
ковый адрес или бит, маркирующий их как не использующиеся. 

















282 


Глава 4. Управление памятью 


Разделение политики и механизма 

Важным инструментом для управления любой комплексной системой является 
отделение политики от механизма. Этот принцип можно применить к управлению 
памятью, осуществив работу большей части управления как процесса на пользо¬ 
вательском уровне. Такое разделение впервые было осуществлено в системах МасЬ 
[366] и МІШХ [322]. Дальнейшие рассуждения приближенно базируются на ра¬ 
боте системы МасЬ. 

Простой пример того, как могут быть разделены стратегия и механизм, пока¬ 
зан на рис. 4.32. Здесь управление памятью делится на три части: 

1. Низкоуровневый драйвер диспетчера памяти (ММИ). 

2. Обработчик страничных прерываний, являющийся частью ядра. 

3. Внешний обработчик страниц, работающий в пользовательском пространстве. 

Все детали работы диспетчера памяти инкапсулированы в драйвере ММІІ Он 
представляет собой машинозависимую программу и должен переписываться для 
каждой новой платформы, на которую переносится операционная система. Обра¬ 
ботчик страничных прерываний является программой, не зависящей от машины, 
и содержит большую часть технических средств для страничной подкачки. По¬ 
литика в основном определяется внешним обработчиком страниц, работающим 
в пользовательском пространстве. 


Пространство I 
пользователя 1 


Пространство 1 
ядра | 


Оперативная память 


У "Іользова 
1 проц 
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Рис. 4.32. Обработка страничного прерывания с внешним обработчиком страниц 

При запуске процесса извещается внешний обработчик страниц для того, что¬ 
бы установить карту страниц процесса и в случае необходимости предоставить 
место на диске для резервного хранения. Во время работы процесс может отобра¬ 
жать новые объекты в свое адресное пространство, о чем опять уведомляется вне¬ 
шний обработчик страниц. 

Как только процесс начинает работу, он может вызвать страничное прерыва¬ 
ние. Обработчик прерываний вычисляет, какая страница требуется, и посылает 
сообщение внешнему обработчику страниц, уведомляя его, в чем заключается 
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проблема. Тогда внешний обработчик страниц считывает нужную страницу с дис¬ 
ка и копирует ее в часть его собственного адресного пространства. Затем он гово¬ 
рит обработчику прерываний, где находится страница. Обработчик прерываний 
убирает отображение страницы из адресного пространства внешнего обработчика 
страниц и просит драйвер МІѴШ поместить ее в нужное место в пользователь¬ 
ском адресном пространстве. После этого можно перезапускать пользовательский 
процесс. 

Эта реализация оставляет открытым вопрос о размещении алгоритма замеще¬ 
ния страниц. Возможно, покажется более удачным расположить его во внешнем 
обработчике страниц, но тогда возникают некоторые проблемы. Из них принци¬ 
пиально то, что внешний обработчик страниц не имеет доступа к битам К и М для 
всех страниц. А эти биты играют важнейшую роль во многих алгоритмах странич¬ 
ной подкачки. Таким образом, или необходим какой-либо механизм для передачи 
содержимого битов внешнему обработчику страниц, или же алгоритм замещения 
страниц должен находиться в ядре. Во втором случае обработчик прерываний со¬ 
общает внешнему обработчику, какую страницу он выбрал для удаления, и предо¬ 
ставляет данные или путем отображения их в адресное пространство внешнего 
обработчика страниц, или включая их в сообщение. В любом варианте внешний 
обработчик страниц пишет данные на диск. 

Основным преимуществом такой реализации является большая модульность 
программы и большая гибкость. Основной недостаток заключается в дополнитель¬ 
ных расходах на несколько переходов границы «пользовательское пространство — 
ядро» и на различные сообщения, пересылаемые между частями системы. В на¬ 
стоящее время этот вопрос вызывает массу дискуссий, но поскольку компьютеры 
приобретают все большую скорость, а программы становятся все более и более 
сложными, вероятно, в итоге большинство разработчиков согласятся принести 
в жертву некоторый процент производительности для того, чтобы иметь более 
надежное программное обеспечение. 


Сегментация 

Обсуждавшаяся до сих пор виртуальная память представляет собой одномерное 
пространство, потому что виртуальные адреса идут один за другим от 0 до некото¬ 
рого максимума. Для многих задач наличие двух и более отдельных виртуальных 
адресных пространств может оказаться намного лучше, чем всего одно. Например, 
у компилятора есть много таблиц, которые формируются по мере трансляции, воз¬ 
можно, включая в себя: 

1. Исходный текст, сохраненный для печати листинга (в пакетных системах). 

2. Символьную таблицу, содержащую имена и атрибуты переменных. 

3. Таблицу, содержащую все используемые константы: целые и с плавающей 
точкой. 

4. Дерево грамматического разбора, содержащее синтаксический анализ про¬ 
граммы. 

5. Стек, используемый для процедурных вызовов внутри компилятора. 
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Во время компиляции каждая из первых четырех таблиц непрерывно растет. 
Последняя таблица при компиляции непредсказуемо увеличивается или уменьша¬ 
ется. В одномерной памяти эти пять таблиц должны были бы размещаться в смеж¬ 
ных частях виртуального адресного пространства, как на рис. 4.33. 

Рассмотрим, что происходит, если программа имеет исключительно большое 
число переменных, но нормальное количество всего остального. Участок адресно¬ 
го пространства, предоставленный для таблицы кодировки символов, может запол¬ 
ниться, но в других таблицах, скорее всего, останется пустым множество ячеек. 
Конечно, компилятор может просто создать сообщение о том, что компиляция не 
может продолжаться вследствие слишком большого количества переменных, но 
нам кажется, что такое решение проблемы не спортивно, когда в других таблицах 
осталась масса неиспользованного места. 


Виртуальное адресное пространство 
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Рис. 4.33. В одномерном адресном пространстве при росте таблиц 
одна может упереться в другую 


При другом варианте можно поиграть в Робин Гуда, забирая пространство из 
таблиц с излишеством ячеек и передавая их таблицам с их недостатком. Такая пе¬ 
ретасовка реализуема, но она аналогична управлению собственными оверлеями, 
что представляет собой маленькое неудобство в лучшем случае и большое коли¬ 
чество скучной и неоплачиваемой работы в худшем случае. 

На самом деле необходим метод, освобождающий программиста от управления 
расширяющимися и сокращающимися таблицами тем же самым способом, которым 
виртуальная память устраняет беспокойство организации программ с оверлеями. 

Простое и предельно общее решение заключается в том, чтобы обеспечить ма¬ 
шину множеством полностью независимых адресных пространств, называемых 
сегментами. Каждый сегмент содержит линейную последовательность адресов от О 
до некоторого максимума. Длина каждого сегмента может быть любой от нуля до 
разрешенного максимума. Различные сегменты могут быть различной длины. Более 
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того, длины сегментов могут изменяться во время выполнения. Длина сегмента 
стека может увеличиваться всякий раз, когда что-либо помещается в стек, и умень¬ 
шаться при выборке данных из стека. 

Поскольку каждый сегмент составляет отдельное адресное пространство, раз¬ 
ные сегменты могут расти или сокращаться независимо друг от друга. Если стек, 
находящийся в определенном сегменте, нуждается в большем количестве адрес¬ 
ного пространства для роста, он может получить его, потому что в его адресном 
пространстве нет больше ничего, с чем можно столкнуться. Конечно, сегмент мо¬ 
жет заполниться, но сегменты обычно очень большие, поэтому такие инциденты 
редки. Чтобы определить адрес в такой сегментированной или двумерной памяти, 
программа должна указать адрес, сос тоящий из двух частей: номер сегмента и адрес 
внутри сегмента. 

Рисунок 4.34 иллюстрирует сегментированную память, использующуюся для 
обсуждавшихся ранее таблиц компилятора. Здесь показаны пять независимых сег¬ 
ментов. 
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ОК 

Рис. 4.34. Сегментированная память позволяет каждой таблице расти 
или уменьшаться независимо от других таблиц 
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3 


Сегмент 

4 


Стоит подчеркнуть, что сегмент — это логический объект, о чем программист 
знает и поэтому использует его как логический объект. Сегмент может иметь в со¬ 
ставе процедуру, массив, стек или набор скалярных переменных, но обычно он не 
содержит смеси различных типов. 

Помимо простоты управления увеличивающимися или сокращающимися струк¬ 
турами данных, сегментированная память обладает и другими преимуществами. 
Если каждая процедура занимает отдельный сегмент и адрес 0 — это ее началь¬ 
ный адрес, компоновка отдельно скомпилированных процедур происходит намно¬ 
го проще. После того как все процедуры, составляющие программу, будут ском¬ 
пилированы и скомпонованы, для адресации слова 0 (начальной точки) обращение 
к процедуре в сегменте п будет использовать адрес, состоящий из двух частей ( п , 0). 
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Если потом процедура в сегменте п модифицируется и компилируется заново, 
не нужно изменять другие процедуры (потому что начальный адрес остался тем 
же), даже если новая версия больше предыдущей. В одномерной памяти процедуры 
упакованы одна к другой и между ними нет свободного адресного пространства. 
В результате изменение размера одной процедуры может повлиять на начальный 
адрес другой, не имеющей отношения к первой процедуре. Это, в свою очередь, 
требует модификации всех процедур, вызывающих любую из передвинутых про¬ 
цедур, чтобы поместить в них новые начальные адреса. Если программа содержит 
сотни процедур, такой процесс очень дорог. 

Сегментация также облегчает совместное использование процедур и данных 
несколькими процессами. Общим примером является библиотека совместного 
доступа. Современные рабочие станции, работающие с передовыми оконными сис¬ 
темами, часто имеют крайне большие графические библиотеки, являющиеся со¬ 
ставляющими практически каждой программы. В сегментированных системах 
графические библиотеки могут располагаться в отдельном сегменте и совместно 
использоваться несколькими процессами, что устраняет необходимость их присут¬ 
ствия в адресном пространстве каждого процесса. В принципе в системах с чистой 
страничной организацией памяти также можно иметь совместно используемые 
библиотеки, но это намного сложнее в реализации. Поэтому такие системы предо¬ 
ставляют совместный доступ путем моделирования сегментации. 

Поскольку каждый сегмент формирует логический объект (такой как проце¬ 
дура, массив или стек), с которым общается программист, у различных сегментов 
могут быть разные виды защиты. Сегмент процедуры может быть определен как 
только исполняемый, что запрещает попытки чтения из него или сохранения в 
него. Для массива чисел с плавающей точкой можно разрешить режим доступа 
чтение/запись, но не исполнение, чтобы отлавливать попытки передачи управле¬ 
ния по адресам, на которых располагается массив. Такая защита полезна при об¬ 
наружении ошибок программирования. 

Вы должны попытаться понять, почему защита имеет смысл в сегментирован¬ 
ной памяти, а не в одномерной страничной памяти. В сегментированной памяти 
пользователь осведомлен о том, что представляет собой каждый сегмент. В обыч¬ 
ном случае сегмент не может содержать, например, и процедуру и стек, а только 
либо первое, либо второе. Так как каждый сегмент содержит только один тип 
объектов, он может иметь защиту, соответствующую этому конкретному типу. 
Страничная организация памяти и сегментация сравниваются в табл. 4.3. 

Содержимое страниц в известной степени случайно. Программист не осведом¬ 
лен даже о том факте, что происходит страничная подкачка. Хотя добавление не¬ 
скольких битов в каждую запись таблицы страниц для определения разрешенного 
доступа в принципе возможно, но, чтобы использовать это свойство, программист 
должен был бы отслеживать, где находятся границы страниц в его адресном про¬ 
странстве. Это представляет собой в точности тот вид администрирования, для 
устранения которого была придумана страничная подкачка. Поскольку пользова¬ 
тель сегментированной памяти имеет дело с иллюзией постоянного нахождения 
всех сегментов в оперативной памяти — то есть он может адресоваться к ним так, 
как будто они существуют, — он может защищать сегменты по отдельности, не забо¬ 
тясь об управлении их загрузкой в память. 
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Таблица 4.3. Сравнение страничной организации памяти и сегментации 


Вопрос 

Страничная память 

Сегментация 

Нужно ли программисту знать о том, 
что используется эта техника? 

Нет 

Да 

Сколько в системе линейных 
адресных пространств? 

1 

Много 

Может ли суммарное адресное пространство 
превышать размеры физической памяти? 

Да 

Да 

Возможно ли разделение процедур и данных, 
а также раздельная защита для них? 

Нет 

Да 

Легко ли размещаются таблицы 
с непостоянными размерами? 

Нет 

Да 

Облегчен ли совместный доступ 
пользователей к процедурам? 

Нет 

Да 

Зачем была придумана эта техника? 

Чтобы получить 
большое линейное 
адресное пространство 
без дополнительных 
затрат на физическую 
память 

Для возможности 
разбиения программ 
и данных на логически 
независимые адресные 
пространства, 
облегчения совместного 
доступа и защиты 


Реализация сегментации 

Реализация сегментации существенно отличается от страничной организации па¬ 
мяти: страницы имеют фиксированный размер, а сегменты — нет. На рис. 4.35, а 
показан пример физической памяти, изначально содержащей пять сегментов. Теперь 
рассмотрим, что произойдет, если удаляется сегмент 1, а на его место помещается 
сегмент 7 меньшего размера. Мы получим конфигурацию памяти, изображенную 
на рис. 4.35, б. Между сегментом 7 и сегментом 2 расположена неиспользуемая 
область, то есть дыра. Затем сегмент 4 замещается сегментом 5 (см. рис. 4.35, в), 
а сегмент 3 заменяется сегментом 6, как на рис. 4.35, г. После того как система пора¬ 
ботает какое-то время, память разделится на некоторое количество участков, часть 
из которых содержит сегменты, а остальные свободны. Этот феномен разделения 
памяти на маленькие свободные участки, которые сложно использовать, называ¬ 
ется поклеточной разбивкой или внешней фрагментацией. С внешней фрагмен¬ 
тацией можно бороться с помощью уплотнения, как показано на рис. 4.35, д. 


Сегментация с использованием 
страниц: система МШ.ТІСЗ 

При большом размере сегментов может быть неудобно или даже невозможно хра¬ 
нить их в оперативной памяти целиком. Это приводит к идее их страничной орга¬ 
низации, чтобы поблизости находились только те страницы, которые на самом деле 
нужны. Страничные сегменты поддерживались несколькими важными для нас 
системами. В этом разделе мы будем описывать первую из них: систему М1ЛЛ1С5. 
В следующем разделе мы обратимся к более современной системе Іпіеі Репііит. 




288 


Глава 4. Управление памятью 


Сегмент 4 


Сегмент 4 


(ЗК) 


(ЗК) 



(7К) 


(7К) 


Сегмент 5 
(4К) 


Сегмент 5 
(4К) 


(10К) 

Сегмент 3 


Сегмент 3 


Сегмент 3 


(4 К) , 








Сегмент 5 
(4К) 

(8 К) 


(8К) 


(8К) 


Сегмент 6 
(4 К) 









Сегмент 6 
(4К) 

Сегмент 2 
(5К) 


Сегмент 2 
(5К) 


Сегмент 2 
(5К) 


Сегмент 2 
(5К) 






Сегмент 2 

Сегмент 1 
(8К) 


(ЗК) 


(ЗК) 


(ЗК) 


(5К) 


Сегмент 7 
(5К) 


Сегмент 7 
(5К) 


Сегмент 7 
(5К) 


Сегмент 7 
(5К) 

Сегмент 0 
(4К) 


Сегмент 0 
(4К) 


Сегмент 0 
(4 К) 


Сегмент 0 
(4К) 


Сегмент 0 
(4К) 


а 


бег 

Рис. 4.35. Развитие внешней фрагментации (а—г); устранение 
фрагментации с помощью уплотнения (д) 


а 


Система ІѴШЬТІСЗ работала на компьютерах Нопеутѵеіі 6000 и их потомках 
и обеспечивала каждую программу виртуальной памятью размером вплоть до 
2 18 сегментов (более 250 000), каждый из которых мог быть до 65 536 (36-разрядных) 
слов длиной. Чтобы осуществить это, разработчики системы МІІЬТІСЗ решили 
трактовать каждый сегмент как виртуальную память и разбить его на страницы, 
комбинируя преимущества страничной организации памяти (постоянный размер 
страницы и отсутствие необходимости хранения целого сегмента в памяти, если 
используется только его часть) с преимуществом сегментации (облегчение про¬ 
граммирования, модульности, защиты и совместного доступа). 

Каждая программа в системе МІІЬТІСЗ имеет таблицу сегментов с одним дес¬ 
криптором на сегмент. Так как записей в таблице потенциально больше четверти 
миллиона, таблица сегментов сама является сегментом и разбита на страницы. 
Дескриптор сегмента содержит индикатор того, находится ли сегмент в памяти или 
нет. Если какая-то часть сегмента присутствует в памяти, считается, что сегмент 
в памяти и его таблица страниц будет в памяти. Если сегмент находится в памя¬ 
ти, то его дескриптор содержит 18-разрядный указатель на его таблицу страниц 
(рис. 4.36, а). Поскольку физические адреса 24-разрядные, а страницы выстраива¬ 
ются по 64-байтным границам (предполагается, что 6 бит низших разрядов адреса 
страницы — это 000000), необходимо только 18 бит в дескрипторе для хранения 
адреса таблицы страниц. Дескриптор также содержит размер сегмента, биты защи¬ 
ты и несколько других полей. Рисунок 4.36, б демонстрирует дескриптор сегмен¬ 
та в системе МІІЕТІС5. Адрес сегмента во вспомогательной памяти не находится 
в дескрипторе сегмента, но в другой таблице используется обработчиком сегмент¬ 
ных прерываний. 

Каждый сегмент представляет собой обыкновенное адресное пространство 
и разбит на страницы точно так же, как и несегментированная страничная память, 
описанная ранее в этой главе. Нормальный размер страницы равен 1024 словам 
(хотя несколько меньшие сегменты, используемые МІІЕТІС5, не разбиты на 
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страницы или же все-таки разделены на страницы по 64 слова, чтобы сохранить 
физическую память). 



Таблица страниц для сегменте 1 


а 


18 


9 1113 3 


Адрес таблицы страниц 

Длина сегмента 





в оперативной памяти 

(в страницах) 



1 



Размер страницы 
О = 1024 слова 
1 = 64 слова 



А 


Л 


0 = сегмент разбит 
на страницы 
1 = сегмент не разбит 
на страницы 


Разносторонние биты 


Биты защиты 


б 

Рис. 4.36. Виртуальная память системы МІАХІСЗ: сегмент дескрипторов указывает 
на таблицы страниц (а); дескриптор сегмента (б). Числа означают длину полей 

Адрес в системе МШЛ1С5 состоит из двух частей: сегмента и адреса внутри 
сегмента. Последний, в свою очередь, делится на номер страницы и слово внутри 
страницы, как показано на рис. 4.37. Когда происходит обращение к памяти, выпол¬ 
няется следующий алгоритм: 

1. По номеру сегмента находится дескриптор сегмента. 

2. Проверяется, находится ли таблица страниц сегмента в памяти. Если табли¬ 
ца страниц в памяти, определяется ее расположение. Если нет, вызывается 
сегментное прерывание. При нарушении защиты происходит прерывание. 
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3. Изучается запись в таблице страниц для запрашиваемой виртуальной стра¬ 
ницы. Если страница не находится в памяти, происходит страничное пре¬ 
рывание. Если она в памяти, из записи таблицы страниц извлекается адрес 
начала страницы в оперативной памяти. 

4. К адресу начала страницы прибавляется смещение, что дает в результате 
адрес в оперативной памяти, где расположено нужное слово. 

5. Наконец, происходит чтение или сохранение. 

Адрес внутри сегмента 


Номер сегмента 
18 


Номер 

Смещение 

страницы 

внутри страницы 

6 

10 


Рис. 4.37. 34-разрядный виртуальный адрес в системе МІЛТІС8 


Этот процесс продемонстрирован на рис. 4.38. Для простоты был опущен тот 
факт, что сегмент дескрипторов сам имеет страничное строение. Реально происхо¬ 
дит следующее: регистр (основной регистр дескриптора) используется для опреде¬ 
ления расположения таблицы страниц сегмента дескрипторов, которая, в свою оче¬ 
редь, указывает на страницы сегмента дескрипторов. Как только дескриптор для 
необходимого сегмента найден, адресация продолжается, как показано на рис. 4.38. 


Виртуальный адрес МШ-ТІСЗ 


Номер сегмента 


Номер 

страницы 

Смещение 



▲ 

Смещение 


Рис. 4.38. Преобразование в системе МІЛ.ТІС5 адреса, состоящего из двух частей, 
в адрес в оперативной памяти 


Как вы, без сомнения, теперь догадались, если бы на практике предыдущий алго¬ 
ритм выполнялся операционной системой для каждой команды процессора, работа 
программы была бы не слишком быстрой. В действительности аппаратура системы 
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М1ЛЛ1С5 содержит высокоскоростной буфер быстрого преобразования адреса 
(ТЬВ) размером в 16 слов, способный производить поиск параллельно по всем своим 
записям для заданного ключа. Это проиллюстрировано на рис. 4.39. Когда компью¬ 
тер получает адрес, аппаратура адресации сначала проверяет наличие виртуального 
адреса в буфере ТЬВ. Если это так, она получает номер страничного блока прями¬ 
ком из буфера ТЬВ и формирует фактический адрес слова, к которому происхо¬ 
дит обращение, не выполняя поиск в сегменте дескрипторов или таблице страниц. 


Поле сравнения 

I* ' Страничный 

Номер Виртуальная д лок 

сегмента страница Защита 


Эта запись 
используется? 


Возраст 




4 

1 

7 

Чтение/запись 

13 

1 

6 

0 

2 

Только чтение 

10 

1 

12 

3 

1 

Чтение/запись 

2 

1 






0 

2 

1 

0 

Только выполнение 

7 

1 

2 

2 

12 

Только выполнение 

9 

1 

_ _ 


_ _ 

_ 

^ _ _ 



Рис. 4.39. Простейший вариант буфера быстрого преобразования адреса (ИВ) 
в системе МІЛ.ТІС5. Существование двух размеров страниц делает фактическое 
строение буфера ИВ более сложным 

Адреса 16 наиболее часто использующихся страниц хранятся в буфере быстро¬ 
го преобразования адреса. Программы, у которых рабочий набор меньше размера 
буфера ТЬВ, будут хранить адреса всего рабочего набора в буфере ТЬВ и, следова¬ 
тельно, будут работать эффективно. Если страница не находится в буфере быстрого 
преобразования адреса, фактически происходит обращение к дескриптору и табли¬ 
це страниц, чтобы найти адрес страничного блока, и буфер ТЬВ обновляется, чтобы 
включить эту страницу. При этом выгружается страница, не использовавшаяся 
дольше всего. Поле «возраста» хранит информацию о том, какая из записей исполь¬ 
зовалась наиболее давно. Причиной для применения буфера ТЬВ служит обеспе¬ 
чиваемое им параллельное сравнение сегментов и номеров страниц всех записей. 

Сегментация с использованием 
страниц: ІпіеІ Репііит 

Виртуальная память на компьютере Репііит во многих отношениях аналогична 
памяти в системе МЕІЕТІС5, включая наличие и сегментации, и страничной орга¬ 
низации. В то время как система МЕІЕТІС5 имеет 256 К независимых сегментов, 
каждый до 64 К 36-разрядных слов, система Репіішп поддерживает 16 К незави¬ 
симых сегментов, каждый до 1 млрд 32-разрядных слов. Хотя в последней системе 
меньше сегментов, их увеличенный размер намного более важен, так как програм¬ 
мы редко нуждаются более чем в 1000 сегментах, но многим программам необхо¬ 
димы сегменты значительного размера. 
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Основа виртуальной памяти системы Репііит состоит их двух таблиц: локаль¬ 
ной таблицы дескрипторов ЬОТ (Ьосаі ОсзсгірТог ТаЫе) и глобальной таблицы 
дескрипторов СОТ (СІоЬаІ Оеьсгіріог ТаЫе). У каждой программы есть своя соб¬ 
ственная таблица ЬОТ, но глобальная таблица дескрипторов одна, ее совместно 
используют все программы в компьютере. Таблица ЬОТ описывает сегменты, ло¬ 
кальные для каждой программы, включая ее код, данные, стек и т. д., тогда как таб¬ 
лица СОТ несет информацию о системных сегментах, включая саму операцион¬ 
ную систему. 

Чтобы получить доступ к сегменту, программа системы Репііиш сначала за¬ 
гружает селектор для этого сегмента в один из шести сегментных регистров маши¬ 
ны. Во время выполнения регистр С5 содержит селектор для сегмента кода команд, 
а регистр 05 хранит селектор для сегмента данных. Каждый селектор представля¬ 
ет собой 16-разрядный номер (рис. 4.40). 

Биты 13 12 

Индекс 


О = СРТ/1 = ЮТ 


' ^Уровень 


привилегированности (0—3) 


Рис. 4.40. Селектор в системе Репііит 


Один из битов селектора несет информацию о том, является ли данный сегмент 
локальным или глобальным (то есть находится ли он в локальной или глобаль¬ 
ной таблице дескрипторов). Следующие тринадцать битов определяют номер за¬ 
писи в таблице дескрипторов, поэтому эти таблицы ограничены: каждая содержит 
8 К сегментных дескрипторов. Остальные 2 бита относятся к проблемам защиты 
и будут описаны позже. Дескриптор 0 является запрещенным. Его можно безопасно 
загрузить в сегментный регистр, чтобы обозначить, что сегментный регистр в дан¬ 
ный момент недоступен. При попытке его использовать происходит прерывание. 

Во время загрузки селектора в сегментный регистр соответствующий дескрип¬ 
тор извлекается из локальной или глобальной таблицы дескрипторов и сохраня¬ 
ется в микропрограммных регистрах, что обеспечивает к нему быстрый доступ. 
Дескриптор состоит из 8 байт, в которые входит базовый адрес сегмента, размер 
и другая информация (рис. 4.41). 

Формат селектора искусно выбирался так, чтобы упростить определение мес¬ 
тоположения дескриптора. Сначала выбирается локальная или глобальная табли¬ 
ца дескрипторов, основываясь на бите два селектора. Затем селектор копируется во 
внутренний рабочий регистр и три младших бита приравниваются к 0. Наконец, 
к нему прибавляется адрес одной из таблиц, чтобы получить прямой указатель на 
дескриптор. Например, селектор 72 ссылается на запись 9 в глобальной таблице 
дескрипторов, расположенную по адресу в таблице СОТ+72. 

Теперь проследим шаги, с помощью которых пара (селектор, смещение) преоб¬ 
разуется в физический адрес. Как только микропрограмма узнает, какой сегмент¬ 
ный регистр используется, она может найти в своих внутренних регистрах пол¬ 
ный дескриптор, соответствующий этому селектору. Если сегмент не существует 
(селектор равен 0) или в данный момент выгружен, возникает прерывание. 
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Рис. 4.41 . Дескриптор программного сегмента в системе Репііит. Сегменты данных 
немного отличаются от программных сегментов 

Затем она проверяет, выходит ли смещение за пределы сегмента, в случае чего 
также возникает прерывание. Логически в дескрипторе просто должно существо¬ 
вать 32-разрядное поле, дающее размер сегмента, но там доступны только 20 бит, 
поэтому используется другая схема. Если поле СЪіІ (^гапиіагііу — глубина де¬ 
тализации) равно 0, поле Ытіі (предел) содержит точный размер сегмента, до 
1 Мбайт. Если оно равно 1, поле Птк дает размер сегмента в страницах вместо бай¬ 
тов. Размер страницы в системе Репііит фиксирован на величине 4 Кбайт, поэто¬ 
му 20 битов достаточно для сегментов размером до 2 32 байтов. 

Предположим, что сегмент находится в памяти, смещение попало в нужный 
интервал, тогда система Репііит прибавляет 32-разрядное поле Вазе (база) в деск¬ 
рипторе к смещению, формируя то, что называется линейным адресом, как показа¬ 
но на рис. 4.42. Поле Вазе разбито на три части, которые разбросаны по дескрипто¬ 
ру для совместимости с процессором Іпіеі 80286, в котором поле Вазе имеет только 
24 бита. В сущности, поле Вазе позволяет каждому сегменту начинаться в произ¬ 
вольном месте внутри 32-разрядного линейного адресного пространства. 



Рис. 4.42. Преобразование пары (селектор, смещение) в физический адрес 

Если разбиение на страницы блокировано (с помощью бита в глобальном 
управляющем регистре), линейный адрес интерпретируется как физический адрес 
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и посылается в память для чтения или записи. Таким образом, при отключенной 
страничной схеме памяти мы получаем чистую схему сегментации с базовым адре¬ 
сом каждого сегмента, выдаваемым его дескриптором. Сегментам разрешено пере¬ 
крываться случайным образом, возможно, потому, что контроль затем, чтобы они 
не пересекались, мог бы причинить достаточно хлопот и занял бы слишком много 
времени. 

С другой стороны, если доступна страничная подкачка, линейный адрес интер¬ 
претируется как виртуальный адрес и отображается на физический адрес с помо¬ 
щью таблицы страниц практически так же, как в наших предыдущих примерах. 
Единственная серьезная трудность заключается в том, что при 32-разряном вирту¬ 
альном адресе и странице размером 4 Кбайт сегмент может содержать 1 млн стра¬ 
ниц, поэтому используется двухуровневое отображение с целью уменьшения раз¬ 
мера таблицы страниц для маленьких сегментов. 

У каждой работающей программы есть страничный каталог, состоящий из 1024 
32-разрядных записей. Он расположен по адресу, хранящемуся в глобальном регис¬ 
тре. Каждая запись в каталоге ссылается на таблицу страниц, также содержащую 
1024 32-разрядных записей. Записи в таблицах страниц в свою очередь указывают 
на страничные блоки. Эта схема продемонстрирована на рис. 4.43. 


Линейный адрес 
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Каталог 


Страница 


Смещение 
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Страничный каталог Таблица страниц Страничный блок 



указывает на страниц указывает 

таблицу каталога на слово 


б 

Рис. 4.43. Отображение линейного адреса на физический адрес 

На рис. 4,43, а мы видим линейный адрес, разделенный на три поля: Каталог, 
Страница и Смещение. Поле Каталог используется как индекс в страничном 
каталоге, определяющий расположение указателя на правильную таблицу стра¬ 
ниц. Затем поле Страница используется в качестве индекса в таблице страниц, 
чтобы найти физический адрес страничного блока. И наконец, чтобы получить 
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физический адрес требуемого байта или слова, к адресу страничного блока при¬ 
бавляется последнее поле Смещение. 

Каждая запись в таблице имеет размер 32 бита, 20 из которых содержат номер 
страничного блока. В остальные биты входят биты доступа и «грязный» бит, 
задаваемые аппаратурой для операционной системы, биты защиты и другие по¬ 
лезные биты. 

Каждая таблица страниц включает в себя записи для 1024 страничных блоков 
размером по 4 Кбайт, таким образом, одна таблица страниц управляет четырьмя 
мегабайтами памяти. Сегмент, длина которого меньше 4 Мбайт, будет иметь 
страничный каталог с единственной записью — указателем на его единственную 
таблицу страниц. Следовательно, в случае короткого сегмента на поддержку 
таблиц страниц расходуется только две страницы вместо миллиона, который был 
бы нужен в одноуровневой таблице страниц. 

Чтобы избежать создания повторных обращений к памяти, система Реп (лит, 
как и система ІѴШЬТІС5, имеет небольшой буфер быстрого преобразования 
адреса (ТЬВ), который напрямую отображает наиболее часто использующиеся 
комбинации Каталог-Страница на физический адрес страничного блока. Только 
когда текущая комбинация отсутствует в буфере ТЬВ, действительно выполняет¬ 
ся механизм, показанный на рис. 4.43, и буфер ТЬВ обновляется. Система облада¬ 
ет хорошей производительностью до тех пор, пока обращения к отсутствующим 
страницам в буфере ТЬВ происходят относительно редко. 

Также следует отметить, что если некоторые приложения не требуют сегмен¬ 
тации, а довольствуются единым, разбитым на страницы 32-разрядным адресным 
пространством, эта модель все равно работает. Все сегментные регистры могут 
быть настроены тем же самым селектором, в дескрипторе которого поле Вазе = 0 
и поле Ытіі установлено на максимум. Тогда, при использовании единственного 
адресного пространства, смещение команды будет линейным адресом — в сущнос¬ 
ти, обычная страничная организация памяти. Фактически все современные опера¬ 
ционные системы для компьютера РепГіиш работают таким образом. Система 05/2 
была единственной, которая использовала всю мощь архитектуры диспетчера 
памяти (М1ѴШ) фирмы Іпіеі. 

В конце концов, кто-то должен похвалить разработчиков системы РепГіиш. При 
поставленных перед ними противоречивых задачах — реализовать чистую странич¬ 
ную организацию памяти, чистое сегментирование и страничные сегменты и в то 
же время обеспечить совместимость с 286-м процессором, а кроме того, сделать все 
это эффективно, — результирующая структура удивительно проста и понятна. 

Мы хотя и кратко, но целиком описали полную архитектуру виртуальной памя¬ 
ти системы Репіішті и теперь следует сказать несколько слов о защите, так как эта 
тема тесно связана с виртуальной памятью. Как схема виртуальной памяти, так и сис¬ 
тема защиты на Репііит близка по модели к системе М1ЛЛ1С5. Система Репііиш 
поддерживает четыре уровня защиты, где уровень 0 является наиболее привилеги¬ 
рованным, а уровень 3 — наименее привилегированным. Они показаны на рис. 4.44. 
В каждый момент времени работающая программа находится на определенном 
уровне, что отмечается 2-битовым полем в его регистре слова состояния програм¬ 
мы (Р5\Ѵ). Каждый сегмент в системе также имеет свой уровень. 
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Типичное 



До тех пор пока программа сама ограничивает использование сегментов на сво¬ 
ем собственном уровне, система прекрасно работает. Разрешаются попытки полу¬ 
чения доступа к данным высшего уровня. Попытки доступа к данным более низ¬ 
кого уровня запрещены и вызывают прерывания. Попытки вызвать процедуры 
различного уровня (более высокого или низкого) позволяются, но тщательно кон¬ 
тролируемым образом. Чтобы сделать межуровневый вызов, инструкция САЬЬ 
должна содержать селектор вместо адреса. Этот селектор определяет дескриптор, 
называемый шлюзом вызова (саіі §а1е), который передает адрес вызываемой про¬ 
цедуры. Таким образом, перепрыгнуть в середину произвольного сегмента кода 
другого уровня невозможно. Могут использоваться только официальные точки 
входа. Концепция уровней защиты и схем вызова впервые появилась в системе 
МШЛ1С5, где они представали в виде колец защиты. 

Типичное использование этого механизма представлено на рис. 4.44. На уровне О 
мы находим ядро операционной системы, занимающееся обработкой операций вво¬ 
да-вывода, управлением памятью и другими наиболее важными вопросами. На 
уровне 1 находится обработчик системных вызовов. На этом уровне пользователь¬ 
ские программы могут обращаться к процедурам для выполнения системных вы¬ 
зовов, но только к определенному и защищенному списку процедур. Уровень 2 
содержит библиотечные процедуры, возможно, совместно используемые нескольки¬ 
ми запущенными программами. Пользовательские программы могут вызывать эти 
процедуры и читать их данные, но не могут их изменять. И наконец, пользователь¬ 
ские программы работают на уровне 3, который имеет наименьшую степень защиты. 

Эмулированные и аппаратные прерывания используют механизм, аналогич¬ 
ный шлюзам вызовов. Они тоже обращаются к дескрипторам, а не к абсолютным 
адресам, эти дескрипторы указывают на определенные процедуры. Поле Тип на 
рис. 4.40 позволяет различать программные сегменты, сегменты данных и различ¬ 
ных видов шлюзов вызовов. 
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Исследования в области 
управления памятью 

Управление памятью, особенно алгоритмы страничной подкачки, когда-то было 
плодотворной областью для исследований, но, кажется, большая часть этих изыс¬ 
каний (по крайней мере, для универсальных систем) сейчас отмерла. Реальные 
системы чаще всего используют некоторые разновидности алгоритма «часы», по¬ 
тому что он прост в реализации и относительно эффективен. Есть, правда, одно 
свежее исключение — доработка системы виртуальной памяти 4.4 В50 [79]. 

Тем не менее до сих пор проводятся исследования, касающиеся страничной 
организации памяти в универсальных и новейших видах систем. Некоторые из 
этих работ направлены на то, чтобы позволить пользовательским процессам обра¬ 
батывать свои собственные страничные прерывания и осуществлять свое собствен¬ 
ное управление памятью, возможно, некоторым специальным способом [НО]. Од¬ 
ной из областей, где могут понадобиться приложения, осуществляющие собственную 
организацию страничной структуры, являются мультимедийные системы, поэтому 
некоторые исследования на эту тему рассматривались в [142]. Другой областью, 
которая имеет некоторые особенные требования, являются портативные персо¬ 
нальные средства связи ([3, 354]). И последняя область — это системы с 64-раз- 
рядным адресным пространством, разделяемым множеством процессов [321]. 


Резюме 

В этой главе было проанализировано управление памятью. Мы увидели, что в про¬ 
стейших системах вообще нет свопинга или страничной организации памяти. Про¬ 
грамма, загруженная в память, остается там до своего завершения. Некоторые опе¬ 
рационные системы позволяют находиться в памяти одновременно только одному 
процессу, в то время как другие поддерживают многозадачность. 

Следующим шагом является свопинг (то есть загрузка и выгрузка целых про¬ 
цессов). Когда используется подкачка такого вида, система может обрабатывать 
большее количество процессов, чем то, для которого достаточно пространства в 
памяти. Процессы, для которых нет места в памяти, целиком выгружаются на диск. 
Свободные области в памяти и на диске могут отслеживаться с помощью битово¬ 
го массива или списка свободных участков. 

Современные компьютеры часто поддерживают некоторую форму виртуальной 
памяти. В простейшем виде адресное пространство каждого процесса делится на 
части постоянного размера, называемые страницами, которые могут размещаться 
в любом доступном страничном блоке в памяти. Существует множество алгорит¬ 
мов замещения страниц, два наилучших — это алгоритмы «старения» и \Ѵ5СІоск. 

Страничные системы можно смоделировать отделением последовательности 
страничных обращений от программы и использованием той же самой строки об¬ 
ращений в различных алгоритмах. Эти модели могут использоваться для некото¬ 
рых прогнозов о характеристиках страничной подкачки. 

Для хорошей работы страничных систем недостаточно выбора алгоритма; кро¬ 
ме этого необходимо обратить внимание на такие вопросы, как определение рабо¬ 
чего набора, стратегию предоставления памяти и размер страниц. 
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Сегментация помогает в управлении структурами данных, изменяющими свой 
размер во время выполнения, и упрощает процессы компоновки и совместного 
доступа. Она также облегчает предоставление различных видов защиты разным 
сегментам. Иногда сегментация и разбивка на страницы комбинируются, чтобы 
обеспечить двумерную виртуальную память. Системы М1ЛЛ1С5 и Іпіеі РепСіиш 
поддерживают сегментацию и страничную организацию памяти. 

Вопросы 

1. Компьютерная система имеет достаточно места для того, чтобы содержать 
в оперативной памяти четыре программы. Эти программы простаивают 
в ожидании ввода-вывода половину времени. Какая часть времени работы 
центрального процессора пропадает? 

2. На рис. 4.20 мы видим пример того, как несколько задач могут работать 
параллельно и при этом закончиться быстрее, чем если бы они были запу¬ 
щены последовательно. Предположим, что одновременно запускаются два 
задания, каждому из которых нужно 10 мин работы процессора. Сколько 
времени потребуется для завершения их работы, если они работают по¬ 
следовательно? А сколько, если они работают параллельно? Предположим, 
ожидание ввода-вывода составляет 50 %. 

3. Системы подкачки устраняют свободные участки с помощью уплотнения. 
Предположим, что множество свободных участков и множество сегментов 
данных распределены случайно, а время для чтения 32-разрядного слова 
в памяти или записи туда равно 10 нс. Сколько примерно времени займет 
уплотнение 128 Мбайт в этом случае? Для простоты считаем, что слово 0 — 
это часть незанятой области и что самое старшее слово памяти содержит дей¬ 
ствительные данные. 

4. В этой задаче сравните количество места, необходимого для учета свобод¬ 
ной памяти при помощи битового массива и с помощью связного списка. 
Память размером 128 Мбайт предоставляется блоками по п байт. Для связ¬ 
ного списка предполагается, что память состоит из чередующейся последо¬ 
вательности сегментов и свободных областей, каждая по 64 Кбайт. Также 
считаем, что для каждого узла в связном списке необходим 32-разрядный 
адрес в памяти, 16 разрядов для длины и 16 разрядов для поля ссылки на 
следующий узел. Сколько потребуется байтов для хранения структур в каж¬ 
дом случае? Какой метод лучше? 

5. Рассмотрим систему обычной подкачки, в памяти которой содержатся свобод¬ 
ные участки следующих размеров и в следующем порядке: 10 Кбайт, 4 Кбайт, 
20 Кбайт, 18 Кбайт, 7 Кбайт, 9 Кбайт, 12 Кбайт и 15 Кбайт. Какой из них 
будет выбран для успешного удовлетворения запроса сегмента размером 

а) 12 Кбайт, 

б) 10 Кбайт, 

в) 9 Кбайт 
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по алгоритму «первый подходящий»? Ответьте на тот же самый вопрос для 
алгоритмов «самый подходящий», «самый неподходящий» и «следующий 
подходящий». 

6. В чем разница между физическим адресом и виртуальным? 

7. Для каждого из следующих десятичных виртуальных адресов вычислите 
номер виртуальной страницы и смещение, если размер страницы равен 
4 Кбайт или 8 Кбайт: 20 000, 32 768, 60 000. 

8. Используя таблицу страниц на рис. 4.10, сосчитайте физический адрес, со¬ 
ответствующий каждому из следующих виртуальных адресов: 

а) 20, 

б) 4100, 

в) 8300. 

9. Процессор Іпіеі 8086 не поддерживает виртуальную память. Тем не менее 
некоторые компании ранее продавали системы, содержащие неизмененный 
процессор 8086 и выполняющие страничную подкачку. Предложите гипо¬ 
тезу того, как они это делали. Подсказка: подумайте о логическом располо¬ 
жении диспетчера памяти (М1ѴШ). 

10. Объем пространства на диске, который должен быть доступен для хранения 
страниц, связан с максимальным количеством процессов п, количеством 
байтов в виртуальном адресном пространстве ѵ и числом байтов в оператив¬ 
ной памяти г. Выведите формулу требований на дисковое пространство 
в худшем случае. Насколько эта величина реалистична? 

11. Считая, что команда выполняется за 10 нс, а страничное прерывание требу¬ 
ет дополнительно п нс, напишите выражение для фактического времени 
выполнения команды с учетом того, что прерывания происходят каждые к 
инструкций. 

12. Машина имеет 32-разрядное адресное пространство и страницы размером 
8 Кбайт. Таблица страниц целиком поддерживается аппаратно, на запись 
в ней отводится одно 32-разрядное слово. При запуске процесса таблица 
страниц копируется из памяти в аппаратуру, одно слово требует 100 нс. Если 
каждый процесс работает в течение 100 мс (включая время загрузки таблицы 
страниц), какая доля времени процессора жертвуется на загрузку таблицы 
страниц? 

13. Компьютер с 32-разрядным адресом использует двухуровневую таблицу 
страниц. Виртуальные адреса расщепляются на 9-разрядное поле верхнего 
уровня таблицы, 11-разрядное поле второго уровня таблицы страниц и сме¬ 
щение. Чему равен размер страниц и сколько их в адресном пространстве? 

14. Предположим, что 32-разрядный виртуальный адрес разбивается на четыре 
поля: а,Ъ,с и д. Первые три используются для трехуровневой системы таб¬ 
лиц страниц. Четвертое поле — это смещение. Зависит ли количество стра¬ 
ниц от размера всех четырех полей? Если нет, то какие из полей имеют зна¬ 
чение, а какие нет? 
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15. Компьютер поддерживает 32-разрядные виртуальные адреса и страницы 
размером 4 Кбайт. Программа и данные вместе умещаются в самую млад¬ 
шую страницу (0-4095). Стек размещается в самой старшей странице. Сколь¬ 
ко записей в таблице страниц необходимо для этого процесса, если ис¬ 
пользуется традиционная (одноуровневая) страничная структура? Сколько 
записей в таблице страниц требуется при двухуровневой страничной струк¬ 
туре, где каждая часть — 10-разрядная? 

16. Ниже показан график выполнения фрагмента программы для компьюте¬ 
ра с размером страницы 512 байт. Программа расположена по адресу 1020, 
указатель стека равен 8192 (стек увеличивается по направлению к нулю). 
Напишите последовательность страничных обращений, создаваемую этой 
программой. Каждая инструкция занимает 4 байта (1 слово), включая не¬ 
посредственные константы. В последовательности обращений учитывают¬ 
ся обращения как к инструкциям, так и к данным. 

1. Загрузить слово 6144 в регистр 0. 

2. Поместить содержимое регистра 0 в стек. 

3. Вызвать процедуру по адресу 5120, помещая в стек адрес возврата. 

4. Вычесть константу 16 из указателя стека. 

5. Сравнить полученный результат с константой 4. 

6. При равенстве перейти на адрес 5152. 

17. Компьютер, чьи процессы имеют 1024 страницы в своем адресном простран¬ 
стве, хранит таблицы страниц в памяти. На чтение слова из таблицы стра¬ 
ниц требуется 5 нс. Чтобы уменьшить затраты, в компьютере существует 
буфер быстрого преобразования адреса (ТЬВ), содержащий 32 пары (вир¬ 
туальная страница, физический страничный блок), который может выпол¬ 
нить поиск за 1 нс. При какой частоте обращений к памяти, успешно реали¬ 
зуемых в ТЬВ, средние затраты будут ниже 2 нс? 

18. Буфер быстрого преобразования адреса на машинах ѴАХ не содержит бита Е. 
Почему? 

19. Как может устройство ассоциативной памяти, требующееся для буфера 
ТБВ, быть реализовано аппаратно и каковы последствия такой конструкции 
для расширяемости? 

20. Машина поддерживает 48-разрядные виртуальные адреса и 32-разрядные 
физические адреса. Размер страницы равен 8 Кбайт. Сколько требуется за¬ 
писей в таблице страниц? 

21. Компьютер с размером страницы 8 Кбайт, размером оперативной памяти 
256 Кбайт и размером виртуального адресного пространства 64 Гбайт ис¬ 
пользует инвертированную таблицу страниц для реализации своей вирту¬ 
альной памяти. Насколько большой должна быть хэш-таблица, чтобы обес¬ 
печить среднее значение длины хэш-цепочки меньше 1? Предположим, что 
размер хэш-таблицы является степенью двойки. 

22. Студент курса конструирования компиляторов предложил профессору про¬ 
ект написания компилятора, получающего список страничных обращений, 
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который может использоваться для реализации оптимального алгоритма 
замещения страниц. Это возможно? Почему «да» или почему «нет»? Суще¬ 
ствует ли какой-нибудь способ, который мог бы повысить эффективность 
страничной подкачки во время работы? 

23. Если используется алгоритм замещения страниц РІРО в системе с четырь¬ 
мя страничными блоками и восемью страницами, сколько страничных пре¬ 
рываний произойдет для последовательности обращений 0172327103 при 
условии, что четыре страничных блока изначально пусты? Теперь решите 
эту задачу для алгоритма ЫШ. 

24. Рассмотрим последовательность страниц на рис. 4.15, 6. Предположим, что 
биты Я для страниц от В до А соответственно равны 11011011. Какая стра¬ 
ница будет следующим кандидатом на удаление? 

25. У маленького компьютера четыре страничных блока. Во время первого тика 
часов биты Я равны 0111 (у страницы 0 бит К равен 0, у остальных — 1). 
Во время последующих тиков часов биты К принимают значения 1011,1010, 
1101, 0010,1010,1100 и 0001. Считая, что используется алгоритм старения 
с 8-разрядным счетчиком, напишите четыре значения, которые примет счет¬ 
чик после последнего тика. 

26. Предположим, что на рис. 4.20 т = 400. Какая страница будет удалена? 

27. В алгоритме ^5С1оск на рис. 4.21, в стрелка указывает на страницу с битом 
К = 0. Если т = 400, будет удалена эта страница? А если т = 1000? 

28. Сколько времени займет загрузка с диска программы размером 64 Кбайт, 
если его среднее время поиска равно 10 мс, время вращения — 10 мс, каждая 
дорожка содержит 32 Кбайт 

а) для размера страницы 2 Кбайт? 

б) для размера страницы 4 Кбайт? 

Страницы раскиданы по диску случайно, и количество цилиндров так ве¬ 
лико, что можно игнорировать вариант, при котором две страницы оказы¬ 
ваются на одном и том же цилиндре. 

29. Компьютер имеет четыре страничных блока. Время загрузки, время послед¬ 
него доступа и биты Я и М для каждой страницы показаны ниже (время 
считается в тиках системных часов): 


Страница Загружена 

Последнее обращение 

К 

М 

0 

126 

280 

1 

0 

1 

230 

265 

0 

01 

2 

140 

270 

0 

0 

3 

ПО 

285 

1 

1 

а) 

Какую страницу выгрузит алгоритм ЫРШ? 



б) 

Какую страницу выгрузит алгоритм ЕІЕО? 



в) 

Какую страницу выгрузит алгоритм ЬИИ? 



г) 

Какую страницу выгрузит алгоритм «вторая попытка»? 
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30. Одна из первых машин с системой разделения времени РОР-1 имела память 
4 К 18-разрядных слов. В каждый конкретный момент времени она содер¬ 
жала в памяти один процесс. Когда планировщик решал запустить другой 
процесс, процесс в памяти записывался на страничный барабан с 4 К 18-раз¬ 
рядных слов по окружности барабана. Барабан мог начать запись (или чте¬ 
ние) с любого слова, а не только со слова 0. Как вы полагаете, почему был 
выбран этот барабан? 

31. Компьютер обеспечивает каждый процесс 65 536 байт адресного простран¬ 
ства, разделенного на страницы по 4096 байт. Некая программа имеет размер 
текста 32 768 байт, размер данных 16 386 байт и размер стека 15 870 байт. 
Поместится ли эта программа в адресном пространстве? А если бы размер 
страницы был 512 байт, она поместилась бы? Помните, что страница не мо¬ 
жет вмещать части двух разных сегментов. 

32. Может ли страница оказаться в двух рабочих наборах одновременно? Объяс¬ 
ните. 

33. Если страница совместно используется двумя процессами, может ли она 
быть страницей «только для чтения» для одного процесса и «чтение-запись» 
для другого процесса? Почему да (или нет)? 

34. Было замечено, что количество инструкций, выполненных между страничны¬ 
ми прерываниями, прямо пропорционально количеству страничных блоков, 
предоставленных программе. Если доступная память увеличивается вдвое, 
то средний интервал между страничными прерываниями также увеличива¬ 
ется вдвое. Предположим, что нормальная инструкция занимает 1 мкс, но 
если происходит страничное прерывание, она выполняется за 2001 мкс (то 
есть 2 мс идут на обработку прерывания). Если программа требует для ра¬ 
боты 60 с, во время которой она вызывает 15 000 страничных прерываний, 
сколько времени она заняла бы, если бы было доступно удвоенное количе¬ 
ство исходной памяти? 

35. Группа разработчиков операционных систем для компании Еги§а1 Сошриіег 
Сотрапу размышляют о способе уменьшения количества резервного про¬ 
странства для хранения, необходимого в их операционной системе. Ведущий 
специалист предложил вообще не беспокоиться о сохранении текста про¬ 
граммы в области подкачки, а просто загружать его страницами прямиком 
из двоичного файла всякий раз, когда он требуется. При каком условии, если 
оно существует, эта идея работает для текста программы? А при каком ус¬ 
ловии, опять же, если оно существует, она работает для данных? 

36. Инструкция машинного языка, загружающая 32-разрядное слово в регистр, 
содержит 32-разрядный адрес этого слова. Какое максимальное количество 
страничных прерываний может вызвать данная команда? 

37. Объясните разницу между внутренней и внешней фрагментацией. Какая из 
них происходит в страничных системах? А какая имеет место в системах, 
использующих чистую сегментацию? 

38. Когда поддерживаются и сегментация, и страничная организация памяти, 
как в системе МШЛЗСЗ, сначала должен быть найден дескриптор сегмента, 
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затем идентификатор страницы. Может ли при таком двухуровневом поис¬ 
ке работать также буфер быстрого преобразования адреса (ТЪВ)? 

39. Составьте гистограмму и вычислите средний и медиановый размеры выпол¬ 
нимых бинарных файлов на своем компьютере. В системе ЛѴіпсІохѵз учтите 
все файлы с расширениями .ехе и .сШ, в системе ІЛЧІХ рассмотрите все вы¬ 
полняемые файлы в каталогах /Ып, /изг/Ып и / Іосаі/Ъіп , которые не являют¬ 
ся сценариями (или используйте утилиту /Не, чтобы найти все выполняемые 
файлы). Определите оптимальный размер страницы для этого компьютера, 
принимая во внимание только код (не данные). Рассмотрите внутреннюю 
фрагментацию и размер таблицы страниц, сделав некоторые разумные пред¬ 
положения о размере записи в таблице страниц. Считайте, что все програм¬ 
мы запускаются с равной вероятностью и таким образом должны учиты¬ 
ваться в расчетах с равным весом. 

40. Маленькие программы для системы М5-005 могут быть скомпилированы 
как .СОМ-файлы. Такие файлы всегда загружаются по адресу 0x100 в един¬ 
ственный сегмент памяти, который используется для кода, данных и стека. 
У инструкций передачи управления, таких как Л1Р и САН, или обращающих¬ 
ся к статическим данным по фиксированным адресам, адреса скомпилиро¬ 
ваны в объектный код. Напишите программу, которая может перенастроить 
адреса в таком программном файле, чтобы выполнить его запуск с произволь¬ 
ного адреса. Ваша программа должна просматривать текст нужной програм¬ 
мы, ища объектные коды команд, обращающихся к фиксированным адре¬ 
сам памяти, затем изменять те адреса, которые указывают на места в памяти 
внутри перемещаемого диапазона. Вы можете найти объектные коды в тек¬ 
сте программы на ассемблере. Заметим, что в общем случае выполнение этой 
задачи полностью и без дополнительной информации невозможно, потому 
что некоторые слова данных могут иметь значения, совпадающие с кодами 
объектных инструкций. 

41. Напишите программу, моделирующую страничную систему. При запуске 
программы следует спросить пользователя об алгоритме страничного замеще¬ 
ния, выбирая из РІРО, ЫШ и, по крайней мере, еще одного. На каждом цикле 
считывайте номер страницы, к которой обращаются, из файла. Сформируйте 
листинг, аналогичный рис. 4.23, но повернутый на 90°, так чтобы каждая 
новая страница увеличивала длину выходного файла на одну строку. 

42. Напишите программу, моделирующую алгоритм последовательности рас¬ 
стояний, описанный в тексте. Входные данные программы — список стра¬ 
ничных обращений (содержащихся в файле) и номер страничного блока 
в доступной физической памяти. Если возможно, используйте последователь¬ 
ность обращений к данным из действительной программы вместо сформи¬ 
рованных случайно страничных обращений. Программа должна содержать 
стек страниц, аналогичный рис. 4.23. При каждом страничном прерывании 
для выбора замещаемой страницы должна вызываться процедура. По завер¬ 
шении работы программа должна печатать последовательность расстояний 
аналогично рис. 4.24. Запустите вашу программу несколько раз для различ¬ 
ных размеров памяти и посмотрите, какие выводы вы можете сделать. 




Глава 5 

Ввод-вывод 


Одна из важнейших функций операционной системы состоит в управлении всеми 
устройствами ввода-вывода компьютера. Операционная система должна давать 
этим устройствам команды, перехватывать прерывания и обрабатывать ошибки. 
Она должна также обеспечить простой и удобный интерфейс между устройства¬ 
ми и остальной частью системы. Интерфейс, насколько это возможно, должен быть 
одинаковым для всех устройств (для достижения независимости от применяемых 
устройств). Программное обеспечение ввода-вывода составляет существенную 
часть операционной системы. Тому, как операционная система управляет устрой¬ 
ствами ввода-вывода, и посвящена эта глава. 

Глава организована следующим образом. Сначала мы рассмотрим некоторые 
основы аппаратуры ввода-вывода, затем в общих чертах познакомимся с программ¬ 
ным обеспечением ввода-вывода. Программное обеспечение ввода-вывода может 
быть структурировано в виде уровней, у каждого из которых есть строго очерчен¬ 
ный круг задач. Мы рассмотрим эти уровни, чтобы понять, что они делают и как 
согласуются друг с другом. 

После этого вступления мы подробно ознакомимся с некоторыми устройствами 
ввода-вывода: дисками, часами, клавиатурами и дисплеями. Для каждого устрой¬ 
ства мы рассмотрим его аппаратную часть и программное обеспечение. Затем мы 
затронем вопрос управления питанием. 


Принципы аппаратуры ввода-вывода 

Разные специалисты рассматривают аппаратуру ввода-вывода с различных точек 
зрения. Инженеры-электронщики видят в них микросхемы, провода, источники 
питания, двигатели и прочие физические компоненты, из которых и состоит аппа¬ 
ратура. Программисты в первую очередь обращают внимание на интерфейс, пре¬ 
доставляемый программному обеспечению, — команды, принимаемые аппарату¬ 
рой, выполняемые ею функции и ошибки, о которых аппаратура может сообщить. 
В этой книге нас интересует именно программирование устройств ввода-вывода, 
а не их проектирование, построение или поддержка. Поэтому сфера наших инте¬ 
ресов будет ограничена тем, как программировать аппаратуру, и в нее не входят 
физические принципы работы аппаратуры. В то же время программирование мно¬ 
гих устройств ввода-вывода часто оказывается тесно связанным с их внутренним 
функционированием. В следующих трех разделах мы кратко предоставим общие 
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основы знаний из области аппаратуры ввода-вывода, касающиеся программиро¬ 
вания. Этот материал можно рассматривать в качестве обзорного и продолжения 
темы раздела «Обзор аппаратного обеспечения компьютера» главы 1. 

Устройства ввода-вывода 

Устройства ввода-вывода можно грубо разделить на две категории: блочные 
устройства и символьные устройства. Блочными называются устройства, храня¬ 
щие информацию в виде блоков фиксированного размера, причем у каждого бло¬ 
ка имеется адрес. Обычно размеры блоков варьируются от 521 до 32 768 байт. 
Важное свойство блочного устройства состоит в том, что каждый его блок может 
быть прочитан независимо от остальных блоков. Наиболее распространенными 
блочными устройствами являются диски. 

Если приглядеться внимательнее, то окажется, что граница между блок-адресуе¬ 
мыми устройствами и устройствами, к отдельным блокам которых нельзя адресо¬ 
ваться напрямую, не определена строго. Все согласны с тем, что диск является 
блок-адресуемым устройством, так как вне зависимости от текущего положения 
головки дисковода всегда можно переместить ее на определенный цилиндр и за¬ 
тем считать или записать отдельный блок с нужной дорожки. Рассмотрим теперь 
накопитель на магнитной ленте (магнитофон), применяемый для хранения резерв¬ 
ных копий диска. На ленте хранится последовательность блоков. Если магнито¬ 
фону дать команду прочитать блок N он всегда может перемотать ленту и начать 
читать блоки, пока не дойдет до запрашиваемого блока N. Эта операция подобна 
поиску блока на диске с той лишь разницей, что она занимает значительно больше 
времени. Кроме того, в зависимости от накопителя и формата хранящихся на нем 
данных, может оказаться возможной или невозможной запись отдельного произ¬ 
вольного блока в середине ленты. Даже если и было бы возможно использовать 
магнитные ленты в качестве блочных устройств произвольного доступа, это явля¬ 
лось бы в какой-то степени натяжкой: никто их не использует таким образом. 

Другой тип устройств ввода-вывода — символьные устройства. Символьное 
устройство принимает или предоставляет поток символов без какой-либо блоч¬ 
ной структуры. Оно не является адресуемым и не выполняет операцию поиска. 
Принтеры, сетевые интерфейсные карты, мыши (для указания точки на экране), 
крысы (для лабораторных экспериментов по психологии) и большинство других 
устройств, не похожих на диски, можно рассматривать как символьные устройства. 

Такая схема классификации не совершенна. Некоторые устройства просто не 
попадают ни в одну из категорий. Например, часы не являются блок-адресуемы- 
ми. Они также не формируют и не принимают символьных потоков. Вся их работа 
состоит в инициировании прерываний в строго определенные моменты времени. 
Экраны отображения памяти также не втискиваются в рамки этой модели. И все 
же модель блочных и символьных устройств является настолько общей, что может 
использоваться в качестве основы для достижения независимости от устройств не¬ 
которого программного обеспечения операционных систем, имеющего дело с вво¬ 
дом-выводом. Например, файловая система имеет дело с абстрактными блочны¬ 
ми устройствами, а зависимую от устройств часть составляет программному 
обеспечению низкого уровня. 
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Устройства ввода-вывода покрывают огромный диапазон скоростей, что созда¬ 
ет определенные трудности для программного обеспечения, которому приходится 
обеспечивать хорошую производительность на скоростях передачи данных, раз¬ 
личающихся несколькими порядками. В табл. 5.1 приведены скорости данных 
для некоторых часто встречающихся устройств. Со временем у многих устройств 
появляются все более быстрые новые модели. 

Таблица 5.1. Скорости данных типичных устройств 

Устройство 

Скорость данных 

Клавиатура 

10 байт/с 

Мышь 

100 байт/с 

Модем 56 К 

7 Кбайт/с 

Телефонная линия 

8 Кбайт/с 

Двойная линия ІЗйМ 

16 Кбайт/с 

Лазерный принтер 

100 Кбайт/с 

Сканер 

400 Кбайт/с 

Классическая сеть ЕіЬегпеІ 

1,25 Мбайт/с 

Шина 115В (ЦпіѵегзаІ ЗегіаІ Виз) 

1,5 Мбайт/с 

Цифровая видеокамера 

4 Мбайт/с 

ЮЕ-диск 

5 Мбайт/с 

40х СР-ЙОМ 

6 Мбайт/с 

Быстрая сеть ЕіЬегпеІ 

12,5 Мбайт/с 

Шина І5А 

16,7 Мбайт/с 

ЮЕ-диск (АТА-2) 

16,7 Мбайт/с 

РігеѴѴІге (ІЕЕЕ 1394) 

50 Мбайт/с 

ХОА-монитор 

60 Мбайт/с 

СетьЗОЫЕТ ОС-12 

78 Мбайт/с 

Диск 5С5І ЦІІга 2 

80 Мбайт/с 

Гигабитная сеть ЕіЬегпеІ 

125 Мбайт/с 

Лента ЦІІгіит 

320 Мбайт/с 

Шина РСІ 

528 Мбайт/с 

Объединительная плата Зип Сідаріапе ХВ 

20 Гбайт/с 


Контроллеры устройств 

Устройства ввода-вывода обычно состоят из механической части и электронной 
пасти. Часто эти части можно разделить для придания модели более модульного 
н общего вида. Электронный компонент устройства называется контроллером 
устройства или адаптером. В персональных компьютерах он часто принимает 
форму печатной платы, вставляемой в слот расширения. Механический компонент 
находится в самом устройстве. Такая организация показана на рис. 1.5. 

Плата контроллера обычно снабжается разъемом, к которому может быть 
подключен кабель, ведущий к самому устройству. Многие контроллеры способны 
управлять двумя, четырьмя или даже восемью идентичными устройствами. Если 
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интерфейс между контроллером и устройством является стандартным, то есть 
официальным стандартом АЫ5І, ІЕЕЕ или 150 либо фактическим стандартом, 
тогда различные компании могут выпускать отдельно контроллеры и устройства, 
удовлетворяющие данному интерфейсу. Так, многие компании производят жест¬ 
кие диски, соответствующие интерфейсу ГОЕ или 5С5І. 

Интерфейс между устройством и контроллером часто является интерфейсом 
очень низкого уровня. Например, какой-нибудь жесткий диск может быть отфор¬ 
матирован по 256 секторов на дорожку, с размером секторов по 512 байт. В дей¬ 
ствительности с диска в контроллер поступает последовательный поток битов, 
начинающийся с заголовка сектора (преамбулы), за которым следует 4096 бит 
в секторе, и, наконец, контрольная сумма, также называемая кодом исправления 
ошибок (ЕСС, Еггог-Соггес1іп§ Сосіе). Заголовок сектора записывается на диск 
во время форматирования. Он содержит номера цилиндра и сектора, размер сек¬ 
тора, информацию синхронизации и т. п. 

Работа контроллера заключается в конвертировании последовательного пото¬ 
ка битов в блок байтов и выполнение коррекции ошибок, если это необходимо. 
Обычно байтовый блок собирается бит за битом в буфере контроллера. Затем про¬ 
веряется контрольная сумма блока, и если она совпадает с указанной в заголовке 
сектора, блок объявляется считанным без ошибок, после чего он копируется в опе¬ 
ративную память. 

Контроллер монитора (видеоадаптер) также работает как бит-последовательное 
устройство, на таком же низком уровне. Он считывает в памяти байты, содержащие 
символы, которые следует отобразить, и формирует сигналы, используемые для 
модуляции луча электронной трубки, заставляющие ее выводить изображение на 
экран. Видеоадаптер также формирует сигналы, управляющие горизонтальным 
и вертикальным возвратом электронного луча. Если бы ни контроллер, про¬ 
граммисту пришлось бы управлять перемещениями аналогового электронного 
луча. В действительности же операционная система всего лишь инициализирует 
контроллер, задавая небольшое число параметров, таких как количество символов 
или пикселов в строке и число строк на экране, а всю тяжелую работу по управле¬ 
нию передвижениями электронного луча по экрану выполняет контроллер. 

Отображаемый на адресное 
пространство памяти ввод-вывод 

У каждого контроллера есть несколько регистров, с помощью которых с ним мо¬ 
жет общаться центральный процессор. При помощи записи в эти регистры опера¬ 
ционная система велит устройству предоставить данные, принять данные, вклю¬ 
читься или выключиться и т. п. Читая из этих регистров, операционная система 
может узнать состояние устройства, например готово ли оно к приему новой 
команды и т. д. 

Помимо управляющих регистров, у многих устройств есть буфер данных, из 
которого операционная система может читать данные, а также писать данные в него. 
Например, для отображения пикселов на экране данные обычно помещаются в ви¬ 
деопамять, являющуюся, по сути, буфером данных, доступным операционной 
системе и другим программам для чтения и записи. 
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Существует два альтернативных способа реализации доступа к управляющим 
регистрам и буферам данных устройств ввода-вывода. Первый вариант заключа¬ 
ется в том, что каждому управляющему регистру назначается номер порта ввода- 
вывода, 8- или 16-разрядное целое число. При помощи такой специальной коман¬ 
ды процессора, как 

ІМ КЕ6.Р0КТ 

центральный процессор может прочитать управляющий регистр устройства из 
порта РОРТ в регистр процессора РЕ6. Аналогично с помощью команды 

(Ж РОКТ.КЕ0 

центральный процессор может записать содержимое своего регистра РЕС в управ¬ 
ляющий регистр устройства через порт РОРТ. Подобным образом работали самые 
древние компьютеры, включая почти все мэйнфреймы, такие как ІВМ 360 и его 
преемники. 

При такой схеме адресные пространства оперативной памяти и устройств вво¬ 
да-вывода не пересекаются, как видно из рис. 5.1, а. Команды 

™ КО.4 


И 

МОѴ КО.4 

выполняют принципиально различные действия. Первая команда читает содержи¬ 
мое порта ввода-вывода 4 в регистр РО, тогда как вторая читает в этот же регистр 
содержимое слова памяти по адресу 4. Таким образом, четверки в этих командах 
означают различные адреса из непересекающихся адресных пространств. 


Два адресных 
пространства 


Одно адресное 
пространство 


Два адресных 
пространства 


ОхРРРР... 


0 



Рис. 5.1. Раздельные адресные пространства (а); отображаемый на адресное пространство 

памяти ввод-вывод (б); гибрид (в) 


Второй подход, впервые реализованный в компьютере РЭР-11, состоял в ото¬ 
бражении всех управляющих регистров периферийных устройств на адресное про¬ 
странство памяти, как показано на рис. 5.1, б. Каждому управляющему регистру 
назначался уникальный адрес в памяти. Такая система называется отображае¬ 
мым на адресное пространство памяти вводом-выводом. Обычно для регистров 
устройств отводятся адреса на вершине адресного пространства. Также существу- 
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ют различные гибридные схемы, с отображаемыми на адресное пространство па¬ 
мяти буферами данных и отдельными портами ввода-вывода (рис. 5.1, в). Эта схе¬ 
ма довольно широко применяется, например, в совместимых с ІВМ РС компьюте¬ 
рах на базе процессоров х86 и Репііиш, в которых, помимо портов ввода-вывода 
с номерами от 0 до 64 К, адресное пространство оперативной памяти от 640 К до 
1 М зарезервировано под буферы данных устройств ввода-вывода. 

Как работают все эти схемы? Во всех случаях, когда центральный процессор 
хочет прочитать слово данных либо из памяти, либо из порта ввода-вывода, он 
выставляет нужный адрес на адресную шину, после чего выставляет сигнал КЕАБ 
на управляющую шину. Вторая сигнальная линия позволяет отличить обращение 
к памяти от обращения к порту. В зависимости от состояния этой линии шины 
управления на запрос процессора реагирует устройство (контроллер) ввода- 
вывода или память. Если пространство адресов общее (как на рис. 5.1, б), то каж¬ 
дый модуль памяти и каждое устройство ввода-вывода сравнивает выставленный 
на шину адрес с обслуживаемым им диапазоном адресов. Если выставленный на 
шину адрес попадает в этот диапазон, то соответствующе устройство реагирует на 
запрос процессора. Поскольку выделенные внешним устройствам адреса удаля¬ 
ются из памяти, память не реагирует на них и конфликта адресов не происходит. 

Обе схемы обращения к контроллерам имеют свои сильные и слабые стороны. 
Начнем с достоинств отображаемого на адресное пространство памяти ввода-вы¬ 
вода. Во-первых, при такой схеме для обращения к устройствам ввода-вывода не 
требуются специальные команды процессора, такие как Ш и 01Л. В результате про¬ 
грамму, общающуюся с таким устройством, можно написать целиком на языке С 
или С++, без вставок на ассемблере или обращений к подпрограммам, написан¬ 
ным на ассемблере, то есть без дополнительных накладных расходов. 

Во-вторых, при отображении регистров ввода-вывода на память не требуется 
специального механизма защиты от пользовательских процессов, пытающихся 
обращаться к внешним устройствам. Все, что нужно сделать операционной систе¬ 
ме, — это исключить ту часть адресного пространства, на которую отобража¬ 
ются управляющие регистры устройств ввода-вывода из адресного пространства 
пользователей. Более того, если управляющие регистры различных устройств вво¬ 
да-вывода отображаются на различные страницы памяти, операционная система 
может предоставить доступ к различным страницам различным пользователям, 
таким образом предоставляя пользователям доступ к одним устройствам и запре¬ 
щая доступ к другим. Для этого нужно всего лишь включить номер соответствую¬ 
щей страницы памяти в карту памяти нужного пользователя. В результате такая 
схема позволяет разместить драйверы различных устройств в различных адресных 
пространствах, тем самым не только уменьшая размер ядра, но и удерживая драй¬ 
веры от вмешательства в дела друг друга. 

В-третьих, при отображении регистров ввода-вывода на память каждая команда 
процессора, обращающаяся к памяти, может с тем же успехом обращаться к управ¬ 
ляющим регистрам устройства. Например, если у процессора есть в наборе команд 
инструкция ТЕ5Т, проверяющая содержимое некоего слова в памяти на равенство О, 
она может с тем же успехом применяться и при обращении к управляющему реги¬ 
стру устройства ввода-вывода. Управляющий регистр, равный 0, будет означать, 
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например, готовность данного устройства к приему новой команды. Программа на 
ассемблере может выглядеть следующим образом: 


ЮОР: 

ТЕ5Т 

РОКТ 4 

// 

сравнить содержимое порта 4 с 

нулей 


ВЕС! 

КЕАОУ 

// 

если он равен 0. идти на метку 

■ КЕАОУ 

КЕАРУ: 

вшсн 

ЦООР 

// 

в противном случае продолжать 

опрос порта 


Если отображения регистров ввода-вывода на память нет, управляющий ре¬ 
гистр устройства должен быть сначала считан в регистр процессора, а уже затем 
сравнен с 0, что требует двух команд процессора вместо одной. Для приведенного 
выше цикла добавление четвертой команды может слегка снизить (все зависит от 
конкретных процессоров, конечно) скорость реакции драйвера на появление при¬ 
знака готовности устройства. 

В разработке компьютеров практически у любого решения есть как положи¬ 
тельные, так и отрицательные стороны. Отображение регистров ввода-вывода на 
память также обладает недостатками. Во-первых, в большинстве современных 
компьютеров применяется кэширование памяти. Кэширование управляющих ре¬ 
гистров привело бы просто к катастрофе. Поясним это утверждение на уже приве¬ 
денном выше примере программы, опрашивающей в цикле порт Р0КТ_4. При пер¬ 
вом обращении к этому порту считалось бы верное значение порта, но это значение 
сохранилось бы в кэше. Все последующие обращения к порту Р0КТ_4 на следую¬ 
щих итерациях цикла просто читали бы значение, сохраненное в кэше, и никогда 
не обращались бы к реальному устройству. Таким образом, программа никогда не 
вышла бы из цикла ожидания готовности, так как при кэшировании регистров 
устройств она просто не смогла бы узнать об изменении управляющего регистра. 

Чтобы не допустить такой ситуации, необходима специальная аппаратура, спо¬ 
собная выборочно запрещать кэширование, например, в зависимости от номера 
страницы памяти, к которой обращается процессор. Таким образом, отображение 
регистров ввода-вывода на память увеличивает сложность аппаратуры и операци¬ 
онной системы, которой приходится управлять избирательным кэшированием. 

Во-вторых, при едином адресном пространстве все модули памяти и все устрой¬ 
ства ввода-вывода должны изучать все обращения процессора к памяти, чтобы 
определить, на которые им следует реагировать. Если у компьютера одна общая 
шина (рис 5.2, а), реализовать подобный просмотр всех обращений к памяти все¬ 
ми устройствами несложно. 

Однако в конструкции современных персональных компьютеров наблюдает¬ 
ся тенденция в сторону использования выделенной высокоскоростной шины 
(рис 5.2, б), архитектурной особенности, кстати, уже давно применявшейся в мэйн¬ 
фреймах. Эта шина предназначена для увеличения скорости обмена данными меж¬ 
ду процессором и памятью, чему в архитектуре общей шины сильно мешали мед¬ 
ленные устройства ввода-вывода. В компьютерах на базе процессора РепСішп таких 
внешних шин целых три (шина памяти, РСІ и 15 А), как было показано на рис. 1.11. 

Сложность применения выделенной шины памяти на машинах с отображени¬ 
ем регистров ввода-вывода на память состоит в том, что у устройств ввода-вывода 
нет способа увидеть адреса памяти, выставляемые процессором на эту шину, сле¬ 
довательно, они не могут реагировать на такие адреса. Поэтому, чтобы отобра¬ 
жение регистров ввода-вывода могло работать на системах с несколькими шина- 
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ми, необходимы специальные меры. Один способ решения этой проблемы состо¬ 
ит в том, что сначала все обращения к памяти посылаются процессором по выде¬ 
ленной быстрой шине напрямую памяти (чтобы не снижать производительности). 
Если память не может ответить на эти запросы, процессор пытается сделать это 
еще раз по другим шинам. Такое решение работоспособно, но требует дополнитель¬ 
ного увеличения сложности аппаратуры. 


Обращения процессора к памяти 
(чтение и запись) проходят по этой 



ввода-вывода) получать доступ к памяти 

выставляются на шину 

а б 

Рис. 5.2. Архитектура с одной шиной (а); архитектура памяти с двумя шинами (б) 

Второе возможное решение заключается в установке на шину памяти специаль¬ 
ного следящего устройства, передающего все адреса потенциально заинтересован¬ 
ным устройствам ввода-вывода. Проблема, однако, в том, что устройства ввода- 
вывода могут просто не успеть обработать эти запросы с той же скоростью, что и 
память. 

Третье решение, используемое в компьютерах на базе процессора Репіішп 
(рис. 1.11), состоит в фильтрации адресов микросхемой моста РСІ. Эта микросхе¬ 
ма содержит регистры диапазона, заполняемые во время загрузки компьютера. 
Например, диапазон адресов от 640 К до 1 М может быть помечен как не относя¬ 
щийся к памяти. Все адреса, попадающие в подобный диапазон, передаются не 
памяти, а на шину РСІ. Недостаток этой схемы состоит в необходимости приня¬ 
тия во время загрузки решения о том, какие адреса не являются адресами памяти. 
Итак, у каждой схемы есть свои достоинства и недостатки, так что компромиссы 
и уступки неизбежны. 


Прямой доступ к памяти (ОМА) 

Независимо от того, отображаются ли регистры или буферы ввода-вывода на па¬ 
мять или нет, центральному процессору необходимо как-то адресоваться к кон¬ 
троллерам устройств для обмена данными с ними. Центральный процессор может 
запрашивать данные от контроллера ввода-вывода по одному байту, но подобная 
организация обмена данными крайне неэффективна, так как расходует огром¬ 
ное количество процессорного времени. Поэтому на практике часто применяется 
другая схема, называемая прямым доступом к памяти (ОМА, бігесі шешогу ассезз). 
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Операционная система может воспользоваться прямым доступом к памяти только 
при наличии аппаратного БМА-контроллера, который есть у большинства систем. 
Иногда БМА-контроллер интегрируется в другие контроллеры, например в диско¬ 
вый контроллер, но такой дизайн требует оснащения В МА- контроллерами каждо¬ 
го периферийного устройства. Как правило, БМА-контроллер, устанавливаемый 
на материнской плате, обслуживает запросы по передаче данных нескольких раз¬ 
личных устройств ввода-вывода, часто на конкурентной основе. 

Где бы он ни располагался фйзически, ОМА-контроллер может получать дос¬ 
туп к системной шине независимо от центрального процессора, как показано на 
рис. 5.3. Он содержит несколько регистров, доступных центральному процессо¬ 
ру для чтения и записи. К ним относятся регистр адреса памяти, счетчик байтов 
и один или более управляющих регистров. Управляющие регистры задают, какой 
порт ввода-вывода должен быть использован, направление переноса данных (чте¬ 
ние из устройства ввода-вывода или запись в него), единицу переноса (осуществ¬ 
лять перепое данных побайтно или пословно), а также число байтов, которые сле¬ 
дует перенести за одну операцию. 


1. Центральный 
процессор 
программирует 


Диск 





Шина 


Рис. 5.3. Работа РМА-контроллера 

Чтобы понять, как работает БМА, познакомимся сначала с тем, как происхо¬ 
дит чтение с диска при отсутствии ОМА. Сначала контроллер считывает с диска 
блок (один или несколько секторов) последовательно, бит за битом, пока весь блок 
не окажется во внутреннем буфере контроллера. Затем контроллер проверяет кон¬ 
трольную сумму, чтобы убедиться, что при чтении не произошло ошибки. После 
этого контроллер инициирует прерывание. Когда операционная система начинает 
работу, она может прочитать блок диска побайтно или пословно, в цикле сохра¬ 
няя считанное слово или байт в оперативной памяти. 

При использовании БМ А процедура совершенно другая. Сначала центральный 
процессор программирует БМА-котроллер, устанавливая его регистры и указы¬ 
вая таким образом, какие данные и куда следует переместить (шаг 1 на рис. 5.3). 
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Затем процессор дает команду дисковому контроллеру прочитать данные во внут¬ 
ренний буфер и проверить контрольную сумму. Когда данные получены и прове¬ 
рены контроллером диска, ОМА может начинать работу. 

БМА-контроллер начинает перенос данных, посылая дисковому контроллеру 
по шине запрос чтения (шаг 2). Этот запрос чтения выглядит как обычный запрос 
чтения, так что контроллер диска даже не знает, пришел ли он от центрального 
процессора или от контроллера БМА. Обычно адрес памяти уже находится на ад¬ 
ресной шине, так что контроллер диска всегда знает, куда следует переслать сле¬ 
дующее слово из своего внутреннего буфера. Запись в память является еще одним 
стандартным циклом шины (шаг 3). Когда запись закончена, контроллер диска 
также по шине посылает сигнал подтверждения контроллеру ОМА (шаг 4). Затем 
контроллер БМА увеличивает используемый адрес памяти и уменьшает значение 
счетчика байтов. После этого шаги со 2-го по 4 -й повторяются, пока значение счет¬ 
чика не станет равно нулю. По завершении цикла копирования контроллер ОМА 
инициирует прерывание процессора, сообщая ему таким образом, что перенос дан¬ 
ных завершен. Операционной системе не нужно копировать блок диска в память. 
Он уже находится там. 

Контроллеры ОМА значительно различаются по степени своей сложности. 
Самые простые из них за один раз выполняют одну операцию переноса данных, 
как описывалось выше. Более сложные контроллеры могут выполнять сразу не¬ 
сколько подобных операций. У таких контроллеров несколько каналов, каждый 
из которых управляется своим набором внутренних регистров. Центральный про¬ 
цессор начинает с того, что загружает в эти регистры соответствующие парамет¬ 
ры. Все операции переноса данных должны выполняться с различными устрой¬ 
ствами ввода-вывода. После переноса каждого слова данных (шаги 2-4 на рис. 5.3) 
контроллер БМА решает, какое устройство будет им обслужено следующим. Этот 
выбор может производиться циклически или при помощи приоритетной схемы, 
предоставляющей одним устройствам преимущество по сравнению с другими. 
Одновременно несколько запросов могут дожидаться исполнения, при условии, 
что существует способ однозначно отличить подтверждения различных устройств. 
Часто с этой целью для каждого канала ОМА используются различные линии под¬ 
тверждения. 

Многие шины могут работать в двух режимах: в пословном и поблочном. 
Некоторые контроллеры ОМА также могут функционировать в обоих режимах. 
В пословном режиме процедура выглядит так, как описывалось выше: контроллер 
ОМА выставляет запрос на перенос одного слова и получает его. Если цент¬ 
ральному процессору также нужна эта шина, ему приходится подождать. Этот 
механизм называется захватом цикла (сусіе 5Іеа1іп§), потому что контроллер 
устройства периодически «подкрадывается» и забирает случайный цикл шины 
у центрального процессора, слегка его тормозя. В блочном режиме контроллер 
БМ А велит устройству занять шину, сделать серию пересылок и отпустить шину. 
Такой способ действий называется пакетным режимом. Он более эффективен, чем 
захват цикла, поскольку занятие шины требует времени, а в пакетном режиме эта 
процедура выполняется всего один раз для передачи целого блока данных. Недо¬ 
статком этого метода является то, что при переносе большого блока данных он 
может заблокировать центральный процессор и другие устройства на существен¬ 
ный промежуток времени. 
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В обсуждавшейся нами модели, иногда называемой сквозным режимом, кон¬ 
троллер ОМА велит контроллеру устройства переслать данные напрямую в опе¬ 
ративную память. В некоторых ОМА-контроллерах используется также режим, 
при котором контроллер устройства посылает слово данных контроллеру ОМА, 
который затем выставляет на шину еще один запрос для передачи этого слова туда, 
куда его нужно передать. При такой схеме требуется лишний цикл шины на пере¬ 
дачу каждого слова, зато такая схема обладает большей гибкостью, так как также 
позволяет выполнять копирование с устройства на устройство, минуя память, 
и даже из памяти в память. (Для этого нужно сначала дать команду чтения из па¬ 
мяти, а затем команду записи в память, но по другому адресу.) 

Большинство контроллеров ОМА используют для передачи данных физичес¬ 
кие адреса памяти. Чтобы использовать физические адреса памяти, операционная 
система должна преобразовать виртуальный адрес буфера памяти в физический и 
записать этот физический адрес в адресный регистр контроллера ОМА. В некото¬ 
рых контроллерах ОМА применяется альтернативная схема, при которой в кон¬ 
троллер ОМА записывается сразу виртуальный адрес. В этом случае контроллер 
ОМА должен использовать менеджер памяти ММП для преобразования адреса. 
Виртуальный адрес может быть выставлен на адресную шину только в том случае, 
когда ММГ! является частью памяти (что возможно, но редко), а не частью цент¬ 
рального процессора. 

Как мы уже упоминали, до начала операции ОМА диск сначала считывает дан¬ 
ные в свой внутренний буфер. Возможно, вы задаетесь вопросом, почему кон¬ 
троллер не помещает данные прямо в оперативную память, по мере получения их 
с диска. Другими словами, зачем ему нужен внутренний буфер? Тому есть две 
причины. Во-первых, при помощи внутренней буферизации контроллер диска 
может проверить контрольную сумму до начала переноса данных в память. Если 
контрольные суммы не совпадают, формируется сигнал об ошибке и перенос дан¬ 
ных не производится. 

Во-вторых, дело в том, что как только началась операция чтения с диска, биты 
начинают поступать с постоянной скоростью, независимо от того, готов контрол¬ 
лер диска их принимать или нет. Если контроллер диска попытается писать эти 
данные напрямую в память, ему придется делать это по системной шине. Если при 
передаче очередного слова шина окажется занятой каким-либо другим устрой¬ 
ством (например, использующим ее в пакетном режиме), контроллеру диска при¬ 
дется ждать. Если следующее слово с диска прибудет раньше, чем контроллер ус¬ 
пеет сохранить предыдущее, контроллер либо потеряет предыдущее слово, либо 
ему придется сохранять его где-либо еще. Таким образом, необходимость внутрен¬ 
него буферирования становится очевидной. При наличии внутреннего буфера кон¬ 
троллеру диска шина не нужна до тех пор, пока не начнется операция ОМА. В ре¬ 
зультате устройство контроллера диска оказывается проще, так как при операции 
ОМА пересылки данных параметр времени не является критичным. (Некоторые 
древние контроллеры действительно напрямую обращались к памяти, обладая 
внутренним буфером небольшого размера, что часто приводило к ошибкам пере¬ 
грузки при занятости шины.) 

ОМА используется не во всех компьютерах. Главный аргумент против исполь¬ 
зования ОМА состоит в том, что центральный процессор обычно значительно 
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превосходит ЭМА-контроллер по скорости и может выполнить ту же работу зна¬ 
чительно быстрее (если только скорость ограничена не быстродействием устрой¬ 
ства ввода-вывода). При отсутствии другой работы у центрального процессора 
заставлять быстрый центральный процессор ждать, пока медленный контроллер 
ОМА выполнит свою работу, бессмысленно. Кроме того, компьютер без контрол¬ 
лера ОМА, с центральным процессором, выполняющим всю работу программно, 
оказывается дешевле, что крайне важно в производстве компьютеров нижней це¬ 
новой категории (например, встроенных). 


Еще раз о прерываниях 

Мы кратко упомянули прерывания в разделе «Устройства ввода-вывода» главы 1, 
но о них следует сказать еще несколько слов. Структура прерываний типичной 
персональной компьютерной системы проиллюстрирована на рис. 5.4. На аппарат¬ 
ном уровне прерывания работают следующим образом. Когда устройство ввода- 
вывода заканчивает свою работу, оно инициирует прерывание (при условии, что 
прерывания разрешены операционной системой). Для этого устройство выстав¬ 
ляет сигнал на выделенную устройству специальную линию шины. Этот сигнал 
распознается микросхемой контроллера прерываний, расположенной на материн¬ 
ской плате. Контроллер прерываний принимает решение о дальнейших действиях. 

3. Центральный 



Рис. 5.4. Схема прерываний в компьютере. Соединения между устройствами 
и контроллером прерываний в действительности являются специальными 
линиями шины, а не выделенными проводами 


При отсутствии других необработанных запросов прерывания контроллер пре¬ 
рываний обрабатывает прерывание немедленно. Если прерывание уже обрабаты¬ 
вается, и в это время приходит запрос от другого устройства по линии с более низ¬ 
ким приоритетом, то новый запрос просто игнорируется. В этом случае устройство 
продолжает удерживать сигнал прерывания на шине до тех пор, пока оно не будет 
обслужено центральным процессором. 

Для обработки прерывания контроллер выставляет на адресную шину номер 
устройства, требующего к себе внимания, и устанавливает сигнал прерывания на 
соответствующий контакт процессора. 

Этот сигнал заставляет процессор приостановить текущую работу и начать 
выполнять обработку прерывания. Номер, выставленный на адресную шину, 
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используется в качестве индекса в таблице, называемой вектором прерываний, из 
которой извлекается новое значение счетчика команд. Новый счетчик команд 
указывает на начало соответствующей процедуры обработки прерывания. Обыч¬ 
но с этого места аппаратные и эмулированные прерывания используют один и тот 
же механизм и часто пользуются одним и тем же вектором. Расположение вектора 
может быть либо жестко прошито на аппаратном уровне, либо, наоборот, распола¬ 
гаться в произвольном месте памяти, на которое указывает специальный регистр 
процессора, загружаемый операционной системой. 

Вскоре после начала своей работы процедура обработки прерываний подтверж¬ 
дает получение прерывания, записывая определенное значение в порт контрол¬ 
лера прерываний. Это подтверждение разрешает контроллеру издавать новые 
прерывания. Благодаря тому, что центральный процессор откладывает выдачу 
подтверждения до момента, когда он уже готов к обработке нового прерывания, 
удается избежать ситуации состязаний при появлении почти одновременных пре¬ 
рываний от нескольких устройств. Следует упомянуть, что на некоторых старых 
компьютерах нет микросхемы, централизованного контроллера прерываний, по¬ 
этому контроллер каждого устройства выставляет свое собственное прерывание. 

Аппаратура всегда, прежде чем начать процедуру обработки прерывания, со¬ 
храняет определенную информацию. Сохраняемая информация и место ее хра¬ 
нения широко варьируются в зависимости от центрального процессора. Как 
минимум сохраняется счетчик команд, что позволяет продолжить выполнение 
прерванного процесса. Другая крайность представляет собой сохранение всех про¬ 
граммно доступных регистров и большого количества внутренних регистров цен¬ 
трального процессора. 

Место сохранения этой информации также оказывается проблемой. Один из 
вариантов состоит в том, чтобы сохранять эти данные в неких внутренних регист¬ 
рах, доступных операционной системе. Недостаток такого подхода — до тех пор, 
пока вся сохраненная информация не будет считана обработчиком прерываний, 
новые прерывания будет нельзя разрешать. В противном случае любое новое пре¬ 
рывание просто стерло бы всю сохраненную таким образом информацию, записав 
поверх нее новые данные. В результате прерывания оказываются запрещенными 
в течение довольно длительных интервалов времени, что приводит к возможному 
игнорированию некоторых сигналов прерывания от устройств и, соответственно, 
к возможной потере данных. 

Поэтому большинство центральных процессоров сохраняют информацию в сте¬ 
ке. Однако у этого подхода также имеются недостатки. Во-первых, в чьем стеке 
следует сохранять данные? Если использовать текущий стек, он может оказаться 
стеком процесса пользователя. При этом может даже выясниться, что пользова¬ 
тель использует указатель стека в своей программе весьма нестандартно, то есть 
стек может указывать на область памяти, в которой нельзя сохранять данные. По¬ 
пытка записать несколько слов в стек в таком случае может привести к неиспра¬ 
вимой ошибке. Также указатель стека может указывать на конец страницы памя¬ 
ти. После нескольких обращений к стеку указатель может достичь конца страницы 
памяти и вызвать соответствующую ошибку. Если во время обработки аппаратно- 
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го прерывания произойдет обращение к отсутствующей странице, это станет еще 
большей проблемой: где сохранить состояние процедуры обработки прерывания 
для обработки данной ошибки? 

Использовать стек ядра гораздо проще, так как при этом больше шансов, что 
указатель стека указывает на область памяти, в которой можно сохранять данные. 
Однако переключение в режим ядра может потребовать изменения контекста 
ММИ и, возможно, обесценит большую часть содержимого кэша и ТЬВ (Т гапзіаііоп 
Ьооказісіе Виііег — буфер быстрого преобразования адреса). Перегрузка всех этих 
кэшей статически или динамически увеличит время обработки прерывания и вы¬ 
зовет растрату процессорного времени. 

Другая проблема вызванатем фактом, что большинство современных централь¬ 
ных процессоров широко используют конвейеры и часто являются суперскаляр¬ 
ными (внутренне параллельными). В более старых системах после выполнения 
каждой команды процессора микропрограмма или аппаратура проверяли, нет ли 
прерывания, ждущего обработки. Если таковое было, счетчик команд и слово со¬ 
стояния процессора (Р5\Ѵ) сохранялись в стеке и начиналась обработка пре¬ 
рывания. По завершении работы обработчика прерывания происходила обратная 
процедура: старые значения Р5\Ѵ и счетчика команд извлекались из стека, и пре¬ 
рванный процесс возобновлялся. 

Такая модель явно предполагает, что к приходу прерывания все команды про¬ 
цессора до этого момента выполнены полностью и ни одна команда процессора 
после последней выполненной команды не начала выполняться. На старых маши¬ 
нах такое предположение было оправдано. Однако на современных компьютерах 
это не всегда так. 

Для начала рассмотрим модель конвейера на рис. 1.6, а. Что произойдет, если 
прерывание придет, когда конвейер полон (вполне обычный случай)? Различные 
команды окажутся на разных стадиях выполнения. К приходу прерывания значе¬ 
ние счетчика команд может не отражать истинной границы между уже выполнен¬ 
ными и еще не выполненными командами. Скорее всего, он будет указывать на 
адрес очередной команды, которую следует выбрать из памяти и поместить в кон¬ 
вейер, а не на адрес команды, только что обработанной исполнительным блоком. 

В результате даже при наличии строго очерченной границы между уже выпол¬ 
ненными и еще не выполненными командами может оказаться, что аппаратура 
просто не знает, где она проходит. Соответственно, при возврате из прерывания 
операционная система не может просто начать заполнять конвейер с адреса, со¬ 
держащегося в счетчике команд. Она должна сначала узнать, какая команда была 
выполнена последней, что часто является довольно сложной задачей, требующей 
серьезного анализа состояния процессора. 

Хотя эта ситуация и неприятна, однако прерывания на суперскалярной маши¬ 
не (рис. 1.6, б) значительно хуже. Поскольку команды процессора могут выпол¬ 
няться не в порядке их расположения в памяти, строго очерченной границы между 
уже выполненными и еще не выполненными командами может вообще не оказать¬ 
ся. Может, например, случиться, что команды 1, 2,3,5 и 8 уже выполнены, а коман¬ 
ды 4, 6, 7, 9 и 10 — еще нет. Более того, счетчик команд теперь может указывать, 
например, на команды 9, 10 или 11. 
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Прерывание, оставляющее машину в строго определенном состоянии, называет¬ 
ся точным прерыванием [353]. У такого прерывания четыре следующих свойства: 

1. Счетчик команд (РС, Рго§гаш Соипіег) сохраняется в известном месте. 

2. Все команды до той, на которую указывает счетчик команд, выполнены пол¬ 
ностью. 

3. Ни одна команда после той, на которую указывает счетчик команд, не была 
выполнена. 

4. Состояние команды, на которую указывает счетчик команд, известно. 

Обратите внимание, что здесь не накладывается запрета на начало выполнения 
команд после той, на которую указывает счетчик команд. Утверждается лишь, что 
все изменения с памятью и регистрами процессора, произведенные благодаря на¬ 
чалу выполнения этих инструкций, должны быть отменены прежде, чем начнется 
обработка сигнала прерывания процессором. Разрешается выполнение команды, 
на которую указывает счетчик команд. Также допускается ее невыполнение. Од¬ 
нако должно быть известно, выполнена она или нет. Часто случается, если преры¬ 
вание пришло от устройства ввода-вывода, что выполнение команды, на которую 
указывает счетчик команд, еще и не начиналось. Однако если прерывание было 
эмулировано или вызвано обращением к отсутствующей странице, тогда счетчик 
команд обычно указывает на команду, вызвавшую прерывание. 

Прерывание, не удовлетворяющее данным требованиям, называется неточным 
прерыванием. Такое прерывание крайне портит жизнь программистам, пишущим 
операционную систему, которым приходится в таком случае выяснять, что случи¬ 
лось и чему еще предстоит случиться. Машины с неточным прерыванием обычно 
в случае прерывания выгружают в стек огромное количество данных, чтобы дать 
операционной системе возможность определить, что происходило в этот момент. 
Сохранение больших объемов данных в памяти при каждом прерывании сильно 
замедляет вход в процедуру обработки прерывания, а восстановление после пре¬ 
рывания усложняется еще больше. Все это приводит к нелепой ситуации, в кото¬ 
рой сверхбыстрый суперскалярный центральный процессор оказывается непри¬ 
годен для задач реального времени из-за своих страшно медленных прерываний. 

Некоторые компьютеры спроектированы таким образом, что одни типы преры¬ 
ваний (аппаратных и эмулированных) оказываются точными, тогда как другие — 
неточными. Например, совсем не плохо, если прерывания от устройств ввода-вы¬ 
вода будут точными, а эмулированные прерывания и прерывания, вызванные про¬ 
граммными ошибками, будут неточными, так как последние не требуют возобнов¬ 
ления прерванных процессов. В некоторых машинах имеется специальный бит, 
установив который можно все прерывания сделать точными. Недостатком установ¬ 
ки такого бита является то, что он вынуждает процессор тщательно регистриро¬ 
вать свои действия и сохранять значения регистров в специальных теневых реги¬ 
страх, обеспечивая, таким образом, возможность произвести точное прерывание 
в любой момент времени. Естественно, все эти накладные расходы заметно сни¬ 
жают производительность. 

Некоторые суперскалярные процессоры, такие как Реп (ли т Рго и все его пре¬ 
емники, поддерживают точные прерывания для корректной работы на них про¬ 
грамм, написанных для старых процессоров 386, 486 и Репііиш I. (Первым супер- 
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скалярным процессором серии Іпіеі х86 был процессор РепСіит Рго; у процессора 
РепГіит I было просто два конвейера.) Ценой за точные прерывания оказывается 
крайне сложная внутрипроцессорная логика прерываний. Эта логика должна га¬ 
рантировать, что в случае прихода сигнала прерывания от контроллера прерыва¬ 
ний все команды вплоть до определенной точки могли быть завершены и ни одна 
команда после последней выполненной не должна была оказать заметного эффек¬ 
та на состояние машины. В данном случае ценой, которую приходилось платить 
за возможность точных прерываний на суперскалярном процессоре, являлось не 
время обработки прерывания, а сложность самого процессора и его разработки. 
Если бы можно было отказаться от необходимости поддержки точных прерываний, 
что делалось для обратной совместимости, сэкономленное место на кристалле мож¬ 
но было бы отдать под кэш, а это ускорило бы процессор. С другой стороны, нали¬ 
чие неточных прерываний значительно усложняет и замедляет операционную си¬ 
стему, так что трудно сказать, какой подход на самом деле лучше. 


Принципы программного 
обеспечения ввода-вывода 

Перейдем теперь от рассмотрения аппаратуры ввода-вывода к знакомству с про¬ 
граммным обеспечением ввода-вывода. Сначала мы познакомимся с целями про¬ 
граммного обеспечения ввода-вывода, а затем с различными способами выполне¬ 
ния операций ввода-вывода с точки зрения операционной системы. 

Задачи программного обеспечения ввода-вывода 

Ключевая концепция разработки программного обеспечения ввода-вывода извес¬ 
тна как независимость от устройств. Эта концепция означает возможность напи¬ 
сания программ, способных получать доступ к любому устройству ввода-вывода, 
без предварительного указания конкретного устройства. Например, программа, 
читающая данные из входного файла, должна с одинаковым успехом работать 
с файлом на дискете, жестком диске или компакт-диске. При этом не должны 
требоваться какие-либо изменения в программе. Например, должна быть возмож¬ 
ность дать команду вроде 

50ГІ <іпріЛ >оиІриІ 

и эта команда должна работать, независимо от того, что указано в качестве вход¬ 
ного устройства — гибкий диск, ШЕ-диск, ЗСЗТдиск или клавиатура. В качестве 
выходного устройства также с равным успехом может быть указан экран, файл на 
любом диске или принтер. Все проблемы, связанные с отличиями этих устройств, 
должна решать операционная система. 

Тесно связан с концепцией независимости от устройств принцип единообраз¬ 
ного именования. Имя файла или устройства должно быть просто текстовой стро¬ 
кой или целым числом и никоим образом не зависеть от физического устройства. 
В системе ІЖІХ все диски могут быть произвольным образом интегрированы 
в иерархию файловой системы, так что пользователю не обязательно знать, какое 
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имя какому устройству соответствует. Например, гибкий диск может быть смон¬ 
тирован поверх каталога /иэг/азі/Ьаскир, так что копирование файла в каталог 
/и$г/а$і/Ьаскир/топсІау автоматически приведет к копированию файлов на гиб¬ 
кий диск. Таким образом, все файлы и устройства адресуются одним и тем же спо¬ 
собом: по имени пути. 

Другим важным аспектом программного обеспечения ввода-вывода является 
обработка ошибок. Ошибки должны обрабатываться как можно ближе к аппа¬ 
ратуре. Если контроллер обнаружил ошибку чтения, он должен попытаться по 
возможности исправить эту ошибку сам. Если он не может это сделать, тогда эту 
ошибку должен обработать драйвер устройства, возможно, попытавшись прочитать 
этот блок еще раз. Многие ошибки бывают временными, как, например, ошибки 
чтения, вызванные пылинками на читающих головках. Такие ошибки часто исче¬ 
зают при повторной попытке чтения блока. Только если нижний уровень не мо¬ 
жет сам справиться с проблемой, о ней следует информировать верхний уровень. 
Во многих случаях восстановление после ошибок может осуществляться на ниж¬ 
нем уровне, прозрачно для верхних уровней, то есть так, что верхние уровни даже 
не будут знать о наличии ошибок. 

Еще одним ключевым вопросом является способ переноса данных: синхронный 
(блокирующий) против асинхронного (управляемого прерываниями). Большин¬ 
ство операций ввода-вывода на физическом уровне являются асинхронными — 
центральный процессор запускает перенос данных и отправляется заниматься чем- 
либо другим, пока не придет прерывание. Программы пользователя значительно 
легче написать, используя блокирующие операции ввода-вывода — после обраще¬ 
ния к системному вызову геасі программа автоматически приостанавливается 
до тех пор, пока данные не появятся в буфере. Тем, чтобы операции ввода-вывода, 
в действительности являющиеся асинхронными, выглядели как блокирующие 
в программах пользователя, занимается операционная система. 

Еще одним аспектом программного обеспечения ввода-вывода является буфе¬ 
ризация. Часто данные, поступающие с устройства, не могут быть сохранены сра¬ 
зу там, куда они в конечном итоге направляются. Например, когда пакет приходит 
по сети, операционная система не знает, куда его поместить, пока не будет изучено 
его содержимое, для чего этот пакет нужно где-то временно сохранить. Кроме того, 
для многих устройств реального времени крайне важными оказываются парамет¬ 
ры сроков поступления данных (например для устройств воспроизведения циф¬ 
рового звука), поэтому полученные данные должны быть помещены в выходной 
буфер заранее, чтобы скорость, с которой эти данные получаются из буфера вос¬ 
производящей программой, не зависела от скорости заполнения буфера. Таким 
образом удается избежать неравномерности воспроизведения звука. Буферизация 
включает копирование данных в значительных количествах, что часто является 
основным фактором снижения производительности операций ввода-вывода. 

И последним понятием, которое мы упомянем здесь, является понятие выделен¬ 
ных устройств и устройств коллективного использования. С некоторыми устрой¬ 
ствами ввода-вывода, такими как диски, может одновременно работать большое 
количество пользователей. При этом не должно возникать проблем, если несколь¬ 
ко пользователей на одном и том же диске одновременно откроют файлы. Другие 
устройства, такие как накопители на магнитной ленте, должны предоставляться 
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в монопольное владение одному пользователю, пока он не завершит свою рабо¬ 
ту с этим устройством. После этого накопитель может быть предоставлен другому 
пользователю. Если два или более пользователей одновременно станут писать впе¬ 
ремешку блоки на одну ленту, то ничего хорошего не получится. Введение поня¬ 
тия выделенных (монопольно используемых) устройств также привносит целый 
спектр проблем, например, как взаимоблокировки. Тем не менее операционная 
система должна уметь управлять как устройствами общего доступа, так и выде¬ 
ленными устройствами, позволяя избегать различных потенциальных проблем. 


Программный ввод-вывод 

Существует три фундаментально различных способа осуществления операций 
ввода-вывода. В этом разделе мы рассмотрим первый способ (программный ввод- 
вывод). В следующих двух разделах мы познакомимся с остальными разновидно¬ 
стями ввода-вывода (с управляемым прерываниями вводом-выводом и вводом- 
выводом с использованием БМА). Простейший вид ввода-вывода состоит в том, 
что всю работу выполняет центральный процессор. Этот метод называется про¬ 
граммным вводом-выводом. 

Проще всего проиллюстрировать программный ввод-вывод на примере. Рас¬ 
смотрим процесс пользователя, которому нужно напечатать на принтере строку 
из восьми символов «АВСБЕРСН». Сначала он собирает эту строку в буфере 
в пространстве пользователя (рис. 5.5, а). 


Пространство 

пользователя 


ядра 



АВ 


а б в 

Рис. 5.5. Этапы печати строки 

Затем, обращаясь к системному вызову, процесс пользователя получает прин¬ 
тер во временное пользование. Если принтер в данный момент оказывается занят 
другим процессом, обращение к системному вызову на открытие принтера завер¬ 
шится неудачей. Вызывающему процессу либо будет возвращен код ошибки, либо 
этот процесс будет блокирован до тех пор, пока принтер не освободится, в зави¬ 
симости от операционной системы и параметров вызова. Получив принтер, про¬ 
цесс пользователя обращается к другому системному вызову, прося операционную 
систему распечатать строку на принтере. 
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Операционная система при этом обычно копирует содержимое буфера со стро¬ 
кой в некий массив, расположенный в пространстве ядра, где ей проще получить 
к этим данным доступ (поскольку ядру для получения доступа к пространству 
пользователя, возможно, придется изменять карту памяти). Затем она проверяет, 
доступен ли в данный момент принтер. Если нет, она ждет его освобождения. Как 
только принтер становится доступен, операционная система копирует первый сим¬ 
вол в регистр данных принтера, используя в данном примере отображение реги¬ 
стров устройств ввода-вывода на память. Это действие активизирует принтер. 
На бумаге этот символ может сразу не появиться, так как большинство принтеров 
буферизируют целую строку или даже страницу данных прежде, чем начать 
собственно печать. Однако на рис. 5.5, б мы видим, что первый символ напечатан, 
а указатель операционной системы установлен на следующий символ (В). 

Напечатав первый символ на принтере, операционная система проверяет, го¬ 
тов ли принтер к приему следующего символа. Обычно у принтера есть второй 
регистр, в котором можно прочитать его состояние. При записи символа в регистр 
данных принтер инвертирует бит готовности в статусном регистре. По окончании 
обработки полученного символа контроллером принтера бит готовности снова 
устанавливается, показывая, что принтер готов к приему следующего символа. 

Итак, операционная система ждет, когда принтер снова перейдет в состояние 
готовности. Когда это происходит, она печатает следующий символ (рис. 5.5, в). 
Этот цикл продолжается до тех пор, пока не будет распечатана вся строка. После 
этого управление возвращается процессу пользователя. 

Действия, выполняемые операционной системой, в виде программы на язы¬ 
ке С продемонстрированы в листинге 5.1. Сначала данные копируются в ядро. 
Затем операционная система входит в цикл, в котором на каждой итерации цикла 
печатает на принтере один символ. Существенный аспект программного ввода- 
вывода, ясно проиллюстрированный данным примером, состоит в том, что после 
печати каждого символа процессор в цикле опрашивает готовность устройства. 
Такое поведение процессора называется опросом или ожиданием готовности, 
а также активным ожиданием. 

Листинг 5.1 . Печать строки при помощи программного ввода-вывода 

сору_Ггот_и$ег(ЬиНег. р. соипр); /* р - буфер ядра */ 

бог (і=0: і <соигтЬ: і++){ /* цикл символов */ 

мНіІе (*ргШег_5баби5_гед != КЕАОУ): /* цикл ожидания готовности */ 

* ргі гтЬег_с1а'Ьа_гед = р[і ]: /* печать символа */ 

} 

геРигп_Ьо_и5ег(): 

Программный ввод-вывод очень легко реализуется, но его существенный недо¬ 
статок состоит в том, что центральный процессор занимается на все время опера¬ 
ции ввода-вывода. Даже если один символ «печатается» очень быстро, поскольку 
все, что нужно сделать принтеру — это поместить этот символ в свой внутренний 
буфер, принтер обычно не рассчитан на прием символов с той скоростью, с которой 
их может выдать быстрый процессор. Поэтому большую часть времени централь¬ 
ный процессор проведет в ожидании готовности принтера, что является неэффектив¬ 
ным использованием процессорного времени. Такой подход вполне допустим в при¬ 
митивных встроенных системах, в которых у центрального процессора нет других 
задач; однако в более сложных, многозадачных системах такой подход неприемлем. 
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Управляемый прерываниями ввод-вывод 

Рассмотрим теперь случай принтера, не буферизирующего символы, а печатаю¬ 
щего их сразу по прибытии. Если принтер может печатать, скажем, 100 символов 
в секунду, то на печать каждого символа уходит 10 мс. Это значит, что после запи¬ 
си каждого символа в регистр данных принтера центральный процессор должен 
ждать в цикле целых 10 мс, пока ему не позволят записать в регистр следующий 
символ. Этого времени более чем достаточно для переключения контекста и запус¬ 
ка другого процесса на 10 мс, которые в противном случае просто будут потеряны. 

Предоставить центральному процессору возможность делать что-нибудь в то 
время, когда принтер переходит в состояние готовности, можно при помощи пре¬ 
рываний. Когда выполняется системный вызов печати строки, как мы уже показы¬ 
вали, буфер копируется в пространство ядра и первый символ строки копируется 
на принтер, как только принтер выставит бит готовности. После этого централь¬ 
ный процессор вызывает планировщик, который запускает какой-либо другой про¬ 
цесс. Процесс, попросивший распечатать строку, оказывается заблокирован на весь 
период печати строки. Работа, выполняемая при системном вызове, показана на 
рис. 5.6, а. 


с ору_Ггот_изег(ЬиГТег,р, соипь) ; 
епаЫе_іпСеггирЬз () ; 
мЪіІе (*ргіпЬег_зЬакиз_гед ! =КЕАОУ) ; 
*ргіпЬег_сІа(:а_гедіз(:ег=р [0] ; 
зсЪеДиІег(); 


ІГ (соипЬ==0) { 

ипЫоск_изег () ; 

} еізе { 

*ргіпЬег_сІака_гедізкег=р[і] ; 

соипЬ=соипЬ-1; 

і=і+1; 

} 

аскпо«1есІде_іп(:еггир(: () ; 
геЬигп_Тгот_іпЬеггир(: () ; 


а 


б 


Рис. 5.6. Печать строки при помощи ввода-вывода, управляемого прерываниями: программа, 
выполняемая при обращении к системному вызову (а); процедура обработки прерываний (б) 

Когда принтер напечатал символ и готов принять следующий, он инициирует 
прерывание. Это прерывание вызывает остановку текущего процесса и сохране¬ 
ние его состояния. Затем запускается процедура обработки прерывания от прин¬ 
тера. Грубый вариант этой программы показан на рис. 5.6, б. Если напечатаны все 
символы, обработчик прерывания предпринимает необходимые меры для разбло¬ 
кировки процесса пользователя. В противном случае он печатает следующий сим¬ 
вол, подтверждает прерывание и возвращается к процессу, выполнение которого 
было приостановлено прерыванием от принтера. 


Ввод-вывод с использованием ОМА 

Очевидный недостаток управляемого прерываниями ввода-вывода состоит в том, 
что прерывания происходят при печати каждого символа. Обработка прерываний 
занимает определенное время, поэтому такая схема не является эффективной. 
Решение этой проблемы заключается в использовании ОМА. Идея состоит в том, 
чтобы позволить контроллеру ОМА поставлять принтеру символы по одному, не 
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беспокоя при этом центральный процессор. По существу, этот метод почти не 
отличается от программного ввода-вывода, с той лишь разницей, что всю работу 
вместо центрального процессора выполняет контроллер БМА. Набросок про¬ 
граммы показан на рис. 5.7. 


сору Егот изег (ЪиЕЕег, р, соипЬ) ; 


аскпои1еНде_іп(:еггир(: () ; 

зеЕ ир ОМА сопЫоІІег () ; 


ипЫоск изег () ; 

зсЬеНиІег (); 


геЬигп Егот іпЬеггирЬ (); 


а б 

Рис. 5.7. Печать строки при помощи ОМА: программа, выполняемая при обращении 
к системному вызову (а); процедура обработки прерываний (б) 

Наибольший выигрыш от использования БМА состоит в уменьшении количе¬ 
ства прерываний с одного на печатаемый символ до одного на печатаемый буфер. 
Если символов много, а прерывания обрабатываются медленно, то этот выигрыш 
весьма существенен. С другой стороны, контроллер БМА обычно значительно 
уступает центральному процессору в скорости. Если контроллер ОМА не может 
поддерживать полную скорость ввода или вывода с внешнего устройства, либо 
у центрального процессора нет других задач во время ожидания прерывания от 
БМА, тогда оба предыдущих метода ввода-вывода (программный и управляемый 
прерываниями) будут предпочтительнее. 


Программные уровни ввода-вывода 

Программное обеспечение ввода-вывода обычно организуется в виде четырех 
уровней, показанных на рис. 5.8. У каждого уровня есть четко очерченная функ¬ 
ция, которую он должен выполнять, и строго определенный интерфейс с соседни¬ 
ми уровнями. Функции и интерфейсы уровней меняются от одной операционной 
системы к другой, поэтому последующее рассмотрение всех уровней, начиная с 
нижнего, не является специфичным для какой-либо конкретной машины. 

Обработчики прерываний 

Хотя программный ввод-вывод иногда бывает полезен, для большинства опера¬ 
ций ввода-вывода прерывания являются неприятным, но необходимым фактом. 
Прерывания должны быть упрятаны как можно глубже во внутренностях операци¬ 
онной системы, чтобы о них знала как можно меньшая часть операционной систе¬ 
мы. Лучший способ спрятать их заключается в блокировке драйвера, начавшего 
операцию ввода-вывода, вплоть до окончания этой операции и получения преры¬ 
вания. Драйвер может заблокировать себя сам, выполнив на семафоре процедуру 
бомп, процедуру маіі на переменной состояния, процедуру гесеіѵе на сообщении, 
или что-либо подобное. 

Когда происходит прерывание, начинает работу обработчик прерываний. По 
окончании необходимой работы он может разблокировать драйвер, запустивший 
его. В некоторых случаях используется выполнение процедуры ир на семафоре. 
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В других случаях обработчик прерываний вызывает процедуру монитора зідпаі 
с переменной состояния. В третьем случае он посылает заблокированному драй¬ 
веру сообщение. В любом случае драйвер разблокируется обработчиком прерыва¬ 
ний. Эта схема лучше всего работает в драйверах, являющихся процессами ядра 
со своим собственным состоянием, стеком и счетчиком команд. 



Программное обеспечение ввода-вывода уровня пользователя 


Устройство-независимое программное обеспечение операционной системы 

Драйверы устройств 

Обработчики прерываний 

Аппаратура 


Рис. 5.8. Программные уровни ввода-вывода 


Конечно, в действительности все обстоит совсем не так просто. Обработать пре¬ 
рывание значительно сложнее, чем просто принять его, выполнить ир на семафо¬ 
ре, после чего вернуться из прерывания в предыдущий процесс с помощью коман¬ 
ды процессора ІКЕТ. Операционной системе приходится выполнить значительно 
больше работы. Мы покажем схематичный набросок этой работы в виде набора 
шагов, которые следует выполнить программному обеспечению после того, как 
произошло аппаратное прерывание. Необходимо заметить, что детали во многом 
зависят от конкретной системы, поэтому на каких-то машинах некоторые перечис¬ 
ленные шаги могут оказаться лишними, зато может потребоваться выполнение 
других, не помещенных в список шагов. Кроме того, на разных машинах может 
потребоваться выполнение перечисленных действий в разном порядке. 

1. Сохранить все регистры (включая Р5^Ѵ), не сохраненные аппаратурой. 

2. Установить контекст для процедуры обработки прерываний. Выполнение 
этого действия может включать установку ТЬВ, М МII и таблицы страниц. 

3. Установить указатель стека для процедуры обработки прерываний. 

4. Выдать подтверждение контроллеру прерываний. Если централизованного 
контроллера прерываний нет, разрешить прерывания. 

5. Скопировать содержимое регистров с того места, где они были сохранены 
(возможно, в каком-либо стеке), в таблицу процессов. 

6. Запустить процедуру обработки прерываний. Она извлечет информацию из 
регистров контроллера устройства, инициировавшего прерывание. 

7. Выбрать процесс, которому передать управление. Если прерывание разбло¬ 
кировало какой-либо высокоприоритетный процесс, он может быть выбран 
в качестве следующего. 

8. Установить контекст ММЕІ для следующего работающего процесса. Также 
может понадобиться определенная установка ТЕВ. 

9. Загрузить регистры нового процесса, включая его Р5\Ѵ. 

10. Начать выполнение нового процесса. 
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Как можно заметить, обработка прерываний является далеко не простым де¬ 
лом. Она состоит из значительного количества команд процессора, особенно на 
машинах с виртуальной памятью, на которых необходимо восстанавливать состо¬ 
яние таблиц памяти или сохраненное состояние ММІІ (например, биты К и М). 
На некоторых машинах буфер быстрого преобразования адреса ТЬВ и кэш цент¬ 
рального процессора также требуют управления при переключении режимов 
пользователя и ядра, для чего необходимы дополнительные машинные циклы. 

Драйверы устройств 

Ранее в этой главе мы познакомились с функциями контроллеров устройств вво¬ 
да-вывода. Как было сказано, у каждого контроллера есть набор регистров, исполь¬ 
зуемых для того, чтобы давать управляемому им устройству команды и читать со¬ 
стояние устройства. Число таких регистров и команды, выдаваемые устройствам, 
зависят от конкретного устройства. Например, драйвер мыши должен принимать 
от мыши информацию о том, насколько далеко она продвинулась по горизонтали 
и вертикали, а также о нажатых кнопках мыши. Драйвер диска, в отличие от драй¬ 
вера мыши, должен знать о секторах, дорожках, цилиндрах, головках, их переме¬ 
щении и времени установки, двигателях и тому подобных вещах, необходимых для 
правильной работы диска. Очевидно, что эти драйверы будут сильно различаться. 

Поэтому для управления каждым устройством ввода-вывода, подключенным 
к компьютеру, требуется специальная программа. Эта программа, называемая 
драйвером устройства, обычно пишется производителем устройства и распрост¬ 
раняется вместе с устройством. Поскольку для каждой операционной системы 
требуются специальные драйверы, производители устройств обычно поставляют 
драйверы для нескольких наиболее популярных операционных систем. 

Каждый драйвер устройства обычно поддерживает один тип устройств или, 
максимум, класс близких устройств. Например, драйвер 5С5І-дисков обычно мо¬ 
жет поддерживать различные 5С$І-диски, отличающиеся размерами и скоростя¬ 
ми, и возможно даже будет поддерживать 5С5І СБ-КОМ. С другой стороны, мышь 
и джойстик отличаются настолько сильно, что обычно требуют использования раз¬ 
личных драйверов. Однако нет никакого технического ограничения на управле¬ 
ние одним драйвером нескольких непохожих устройств. Это просто не слишком 
удачная идея. 

Чтобы получить доступ к аппаратной части устройства, то есть к регистрам кон¬ 
троллера, драйвер устройства должен быть частью ядра операционной системы, 
по крайней мере, в существующих на сегодняшний день архитектурах. В действи¬ 
тельности возможно создать и драйвер, работающий в пространстве пользовате¬ 
ля, с системными вызовами для чтения и записи регистров устройств. В самом 
деле, это было бы даже неплохой идеей, так как позволило бы изолировать ядро от 
драйверов, а драйверы друг от друга. При этом была бы устранена основная при¬ 
чина крушения операционной системы — драйверы, содержащие ошибки, сталки¬ 
вающиеся с ядром тем или иным образом. Тем не менее, поскольку современные 
операционные системы предполагают работу драйверов в ядре, мы рассмотрим 
здесь именно такую модель. 
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Так как в операционную систему будут устанавливаться куски программ (драй¬ 
веры), написанные другими программистами, необходима определенная архитекту¬ 
ра, позволяющая подобную установку. Это означает, что должна быть выработана 
строго определенная модель функций драйвера и его взаимодействия с остальной 
операционной системой. Драйверы устройств обычно располагаются под осталь¬ 
ной операционной системой, как показано на рис. 5.9. 


Пространство ) 
пользователя ) 


Пространство < 
ядра 


Аппаратура 


Устройства 


Процесс пользователя 



Рис. 5.9. Логическое расположение драйверов устройств. На самом деле весь обмен 
информацией между драйверами и контроллерами устройств идет по шине 

Операционная система обычно классифицирует драйверы по нескольким кате¬ 
гориям в соответствии с типами обслуживаемых ими устройств. К наиболее общим 
категориям относятся блочные устройства, например, диски, содержащие блоки 
данных, к которым возможна независимая адресация, и символьные устройства, та¬ 
кие как клавиатуры и принтеры, формирующие или принимающие поток символов. 

В большинстве операционных систем определен стандартный интерфейс, кото¬ 
рый должны поддерживать все блочные драйверы, и второй стандартный интерфейс, 
поддерживаемый всеми символьными драйверами. Эти интерфейсы включают 
наборы процедур, которые могут вызываться остальной операционной системой 
для обращения к драйверу. К этим процедурам относятся, например, процедуры 
чтения блока (блочного устройства) или записи символьной строки (для символь¬ 
ного устройства). 
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В некоторых системах операционная система представляет собой единую дво¬ 
ичную программу, содержащую в себе, в откомпилированном вместе с ней виде, 
все необходимые ей драйверы. Такая схема в течение многих лет была нормой для 
систем ІЖІХ, так как они предназначались для работы в компьютерных центрах, 
а устройства ввода-вывода менялись нечасто. При добавлении нового устройства 
системный администратор просто перекомпилировал ядро с новым драйвером, 
получая новый двоичный модуль. 

С появлением персональных компьютеров с их огромным разнообразием устрой¬ 
ств ввода-вывода такая модель перестала работать. Далеко не все пользователи 
могли самостоятельно перекомпилировать и собрать ядро даже при наличии ис¬ 
ходных текстов или объектных модулей, что, кстати, также не всегда имеет место. 
Вместо этого операционные системы, начиная с М5-005, перешли к модели 
динамической подгрузки драйверов во время выполнения системы. Различные 
системы загружают драйверы по-разному. 

У драйвера устройства есть несколько функций. Наиболее очевидная функция 
драйвера состоит в обработке абстрактных запросов чтения и записи независимо¬ 
го от устройств программного обеспечения, расположенного над ними. Но кроме 
этого они должны также выполнять еще несколько функций. Например, драйвер 
должен при необходимости инициализировать устройство. Ему также может по¬ 
надобиться управлять энергопотреблением устройства и регистрацией событий. 

Многие драйверы устройств обладают сходной общей структурой. Типич¬ 
ный драйвер начинает с проверки входных параметров. Если они не удовлетворя¬ 
ют определенным критериям, драйвер возвращает ошибку. В противном случае 
драйвер преобразует абстрактные термины в конкретные. Например, дисковый 
драйвер может преобразовывать линейный номер блока в номера головки, дорожки 
и секторы. 

Затем драйвер может проверить, не используется ли это устройство в данный 
момент. Если устройство занято, запрос может быть поставлен в очередь. Если 
устройство свободно, проверяется аппаратный статус устройства, чтобы понять, 
может ли запрос быть обслужен прямо сейчас. Может оказаться необходимым 
включить устройство или запустить двигатель, прежде чем начнется перенос 
данных. Как только устройство включено и готово, может начинаться собственно 
управление устройством. 

Управление устройством подразумевает выдачу ему серии команд. Именно 
в драйвере определяется последовательность команд в зависимости от того, что 
должно быть сделано. Определившись с командами, драйвер начинает записывать 
их в регистры контроллера устройства. После записи каждой команды в контрол¬ 
лер может быть нужно проверить, принял ли контроллер эту команду и готов ли 
принять следующую. Такая последовательность действий продолжается до тех 
пор, пока контроллеру не будут даны все команды. Некоторые контроллеры спо¬ 
собны принимать связные списки команд, находящихся в памяти. Они сами счи¬ 
тывают и выполняют их без дальнейшей помощи операционной системы. 

После того как драйвер передал все команды контроллеру, ситуация может 
развиваться по двум сценариям. Во многих случаях драйвер устройства должен 
ждать, пока контроллер не выполнит для него определенную работу, поэтому он 
блокируется до тех пор, пока прерывание от устройства его не разблокирует. В дру¬ 
гих случаях операция завершается без задержек и драйверу не нужно блокиро¬ 
ваться. Например, для скроллинга экрана в символьном режиме нужно записать 
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всего лишь несколько байтов в регистры контроллера. Вся операция занимает не¬ 
сколько наносекунд. 

В первом случае заблокированный драйвер будет активизирован прерывани¬ 
ем. Во втором случае драйвер не блокируется. В любом случае по завершении вы¬ 
полнения операции драйвер должен проверить, завершилась ли операция без оши¬ 
бок. Если все в порядке, драйверу, возможно, придется предать данные (например, 
только что прочитанный блок) независимому от устройств программному обеспе¬ 
чению. Наконец, драйвер возвращает некоторую информацию о состоянии для 
информирования вызывающей программы о статусе завершения операции. Если 
в очереди находились другие запросы, один из них теперь может быть выбран и запу¬ 
щен. В противном случае драйвер блокируется в ожидании следующего запроса. 

Эта упрощенная модель является лишь грубым приближением к реальности. 
На самом деле программа значительно сложнее, причиной чему служит большое 
количество разнообразных факторов. Во-первых, устройство ввода-вывода может 
завершить выполнение операции во время работы драйвера, таким образом пре¬ 
рывая его работу. Во-вторых, во время обработки сетевым драйвером пришедше¬ 
го пакета может прийти еще один пакет. Соответственно, драйвер должен быть 
реентерабельным, то есть должен быть готов к тому, что во время обработки пер¬ 
вого вызова может последовать другой вызов. 

В системе с возможностью горячей установки устройства могут добавляться 
или удаляться во время работы системы. В результате в то время, когда драйвер 
занят чтением с какого-либо устройства, система может проинформировать его, 
что пользователь внезапно удалил это устройство из системы. При этом не только 
текущая операция переноса данных должна быть прервана без повреждения струк¬ 
тур данных ядра, но также и все ожидающие обработки запросы к теперь исчезнув¬ 
шему устройству должны быть корректно удалены из системы, а обратившимся к 
ним программам должна быть сообщена неприятная новость. Более того, неожи¬ 
данное добавление нового устройства может заставить ядро жонглировать ресур¬ 
сами (например, линиями запросов прерывания), отнимая их у одного драйвера и 
предоставляя другому драйверу. 

Драйверам не разрешается обращаться к системным вызовам, но им часто бы¬ 
вает необходимо взаимодействовать с остальным ядром. Обычно разрешаются об¬ 
ращения к некоторым системным процедурам. Например, драйверы обращаются 
к системным процедурам для выделения им аппаратно фиксированных страниц 
памяти в качестве буферов, а также затем, чтобы вернуть эти страницы обратно 
ядру. Кроме того, драйверы пользуются вызовами, управляющими ММІІ, тайме¬ 
рами, контроллером ОМА, контроллером прерываний и т. п. 

Независимое от устройств программное 
обеспечение ввода-вывода 

Хотя некоторая часть программного обеспечения ввода-вывода предназначена 
для работы с конкретными устройствами, другая часть является независимой 
от устройств. Расположение точной границы между драйверами и независимым 
от устройств программным обеспечением зависит от системы (и устройств), так 
как некоторые функции, которые могут быть выполнены независимым от устройств 
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образом, часто выполняются прямо в драйверах из различных соображений, в том 
числе соображений эффективности. Функции, показанные в табл. 5.2, обычно реа¬ 
лизуются в независимом от устройств программном обеспечении. 

Таблица 5.2. Функции независимого от устройств программного обеспечения 

Единообразный интерфейс для драйверов устройств 

Буферизация 

Сообщение об ошибках 

Захват и освобождение выделенных устройств 
Размер блока, не зависящий от устройства 


Основная задача независимого от устройств программного обеспечения состо¬ 
ит в выполнении функций ввода-вывода, общих для всех устройств, и предостав¬ 
лении единообразного интерфейса для программ уровня пользователя. Ниже мы 
рассмотрим некоторые из этих вопросов более подробно. 

Единообразный интерфейс для драйверов устройств 

Главный вопрос операционной системы — как сделать так, чтобы все устройства 
ввода-вывода и драйверы выглядели более-менее одинаково. Если диски, принте¬ 
ры, клавиатуры и т. д. требуют различных интерфейсов, при появлении каждого 
нового устройства будет требоваться переделка операционной системы, что опре¬ 
деленно не является удачной мыслью. 

Этот вопрос связан с интерфейсом между драйверами устройств и остальной 
операционной системой. На рис. 5.10, я показана ситуация, в которой у всех драй¬ 
веров различный интерфейс с операционной системой. Это означает, что функции 
драйвера, доступные системе, отличаются от драйвера к драйверу. Это может 
также означать, что функции ядра, необходимые для драйвера, тоже различаются. 
Все вместе это означает, что взаимодействие с каждым новым драйвером требует 
больших усилий программистов. 




Драйвер Драйвер Драйвер 

диска принтера клавиатуры 


Драйвер Драйвер Драйвер 

диска принтера клавиатуры 


е б 

Рис. 5.10. Стандартный интерфейс драйверов отсутствует (а); 
стандартный интерфейс драйверов присутствует (б) 
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Напротив, на рис. 5.10, б изображен принципиально другой подход, при кото¬ 
ром у всех драйверов один и тот же интерфейс. При этом значительно легче уста¬ 
новить новый драйвер, при условии, что он соответствует стандартному интерфей¬ 
су. Это также означает, что программисты, пишущие драйверы, знают, чего от них 
ожидают (то есть какие функции они должны реализовать и к каким функциям 
ядра они могут обращаться). На практике не все устройства являются абсолютно 
идентичными, но обычно имеется небольшое число типов устройств, достаточно 
сходных друг с другом. Например, даже у блочных и символьных устройств есть 
много общих функций. 

Другой аспект единообразного интерфейса состоит в именовании устройств 
ввода-вывода. Независимое от устройств программное обеспечение занимается 
отображением символьных имен устройств на соответствующие драйверы. Напри¬ 
мер, в системе ІЖІХ имя устройства /беѵ/бізкО однозначно указывает і-узел спе¬ 
циального файла, содержащий номер главного устройства, использующийся для 
определения расположения подходящего драйвера. Этот і-узел также содержит 
номер второстепенного устройства, передаваемый в виде параметра драйверу для 
указания конкретного диска или раздела диска, к которому относится операция 
чтения или записи. Все устройства в системе ІЖІХ имеют главный и второсте¬ 
пенный номера, по которым они однозначно идентифицируются. Выбор всех драй¬ 
веров осуществляется по главному номеру устройства. 

С именованием устройств тесно связан вопрос защиты. Как операционная сис¬ 
тема предотвращает доступ пользователей к устройствам, на который у них нет 
прав? В ІЖІХ и в \Уіпсіо\Ѵ5 2000 устройства представляются в файловой системе 
в виде именованных объектов, что дает возможность применять обычные правила 
защиты файлов к устройствам ввода-вывода. Таким образом, системный админи¬ 
стратор может установить нужные разрешения для каждого устройства. 

Буферизация 

Буферизация также является важным вопросом как для блочных, так и для сим¬ 
вольных устройств по самым разным причинам. Чтобы проиллюстрировать одну 
из причин, рассмотрим процесс, который хочет прочитать данные с модема. Одна 
из возможных стратегий обработки поступающих символов состоит в обращении 
процесса пользователя к системному вызову геасі и блокировке в ожидании отдель¬ 
ного символа. Каждый прибывающий символ вызывает прерывание. Процедура 
обработки прерываний передает символ пользовательскому процессу и разбло¬ 
кирует его. Поместив куда-либо полученный символ, процесс читает следующий 
символ, опять блокируясь. Эта схема проиллюстрирована на рис. 5.11, а. 

Недостаток такого подхода состоит в том, что процесс пользователя должен 
быть активирован при прибытии каждого символа, что крайне неэффективно. 

Улучшенный вариант показан на рис. 5.11, б. Здесь пользовательский процесс 
предоставляет буфер размером в п символов в пространстве пользователя, после 
чего выполняет чтение п символов. Процедура обработки прерываний помещает 
приходящие символы в буфер до тех пор, пока он не заполнится. Затем она акти¬ 
визирует процесс пользователя. Такая схема гораздо эффективнее предыдущей, 
однако у нее также есть недостатки: что случится, если в момент прибытия символа 
страница памяти, в которой расположен буфер, окажется выгруженной из физичес- 
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кой памяти? Конечно, буфер можно зафиксировать в памяти; если слишком мно¬ 
го процессов начнут фиксировать свои страницы в памяти, пул доступных стра¬ 
ниц памяти уменьшится, в результате чего снизится производительность. 


Пространство 

пользователя 


Пространство 

ядра 


Процесс 

пользователя 





Модем 


Модем 



Модем 



Модем 


а б в г 

Рис. 5.11 . Небуферизированный ввод (а); буферизация в пространстве пользователя (б); 
буферизация в ядре с копированием в пространство пользователя (в); 
двойная буферизация в ядре (г) 

Следующий подход состоит в создании буфера, в который обработчик преры¬ 
ваний будет помещать поступающие символы, в ядре, как показано на рис. 5.11, в. 
Когда этот буфер наполняется, достается страница с буфером пользователя, и содер¬ 
жимое буфера копируется туда за одну операцию. Такая схема намного эффективнее. 

Однако даже при использовании этой схемы имеются определенные проблемы. 
Что случится с символами, прибывающими в тот момент, когда страница пользова¬ 
теля загружается с диска? Поскольку буфер полон, их некуда поместить. Решение 
проблемы состоит в использовании второго буфера в ядре, в который помещают¬ 
ся символы после заполнения первого буфера до его освобождения (рис. 5.11, г). 
При этом буферы как бы меняются местами, то есть первый буфер начинает иг¬ 
рать роль запасного. Такая схема часто называется двойной буферизацией. 

Буферизация также играет важную роль при выводе данных. Рассмотрим, 
например, как происходит вывод на модем при помощи модели, показанной на 
рис. 5.11, б. Пользовательский процесс выполняет системный вызов ч/гіЪе для вы¬ 
вода п символов. У системы в этот момент есть выбор. Она может заблокировать 
пользователя, пока все символы не будут записаны, но по медленной телефонной 
линии это может занять довольно много времени. Она может разрешить пользо¬ 
вателю продолжать выполнение немедленно и выполнять операцию ввода-вы¬ 
вода, в то время как пользователь занимается другими вычислениями. Однако 
при этом возникает непростая проблема: как пользовательский процесс узнает, 
что операция вывода завершена и он может опять пользоваться этим буфером? 
Система может подать сигнал или программное прерывание, но такой стиль про¬ 
граммирования сложен и чреват возникновениями ситуаций состязания. Значи¬ 
тельно лучшее решение состоит в копировании данных в буфер ядра, по аналогии 
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с рис. 5.11, в (но в обратном направлении), и немедленном разблокировании вы¬ 
зывающего процесса. Теперь уже не важно, когда будет выполнена физическая 
операция ввода-вывода. Пользователь может использовать буфер сразу после воз¬ 
врата ему управления. 

Буферизация является широко применяемой технологией, однако у нее имеют¬ 
ся свои недостатки. Если при буферизации данные копируются слишком много раз, 
страдает производительность. Рассмотрим, например, сеть (рис. 5.12). Пользова¬ 
тель обращается к системному вызову для записи данных по сети. Ядро копирует 
пакет в буфер ядра, чтобы пользователь мог немедленно продолжить работу (шаг 1). 


Пространство 

пользователя 


Пространство 

ядра 


Процесс 

пользователя 



Сеть ^ 


Рис. 5.12. Копии пакета при передаче его по сети 


При вызове драйвера пакет копируется в контроллер для вывода (шаг 2). Память 
ядра не используется напрямую, так как передача по линии должна производиться 
с постоянной скоростью. Драйвер не может гарантировать, что он сможет получать 
доступ к памяти с постоянной скоростью, так как каналы ОМА и другие устрой¬ 
ства ввода-вывода могут внезапно захватить много циклов шины. Если драйвер 
не сможет предоставить контроллеру вовремя хотя бы одно слово данных, весь 
пакет будет разрушен. Этой проблемы удается избежать при помощи буфериза¬ 
ции пакета целиком внутри контроллера. 

Затем пакет копируется в сеть (шаг 3). Получающая сторона собирает пакет из 
отдельных битов также в буфере сетевого контроллера. После этого пакет копиру¬ 
ется в буфер ядра получателя (шаг 4). Наконец, он копируется в буфер получаю¬ 
щего процесса (шаг 5). Обычно в ответ получатель отправляет подтверждение. 
Получив подтверждение, отправитель может посылать следующий пакет. Однако 
должно быть очевидно, что все эти операции копирования существенно замедляют 
передачу данных, поскольку все эти шаги должны выполняться последовательно. 


Сообщения об ошибках 

Ошибки значительно чаще случаются в контексте ввода-вывода, нежели в других 
контекстах. При возникновении ошибок операционная система должна обработать 
их как можно быстрее. Многие ошибки являются специфичными для конкретно- 
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го устройства и должны обрабатываться соответствующим драйвером, но струк¬ 
тура обработки ошибок является независимой от устройств. 

Один из классов ошибок ввода-вывода составляют ошибки программирования. 
Они происходят, когда процесс просит чего-либо невозможного — например, за¬ 
писать данные на устройство ввода (клавиатуру, мышь, сканер и т. д.) или, наобо¬ 
рот, прочитать данные с устройства вывода (принтера, плоттера и т. п.). Другие 
ошибки включают предоставление неверного адреса буфера или иных параметров, 
а также обращение к несуществующему устройству (например, к диску 3, когда 
у системы всего два диска). Обработка таких ошибок довольно проста: код ошиб¬ 
ки возвращается вызывающему процессу. 

К другому классу ошибок относятся собственно ошибки ввода-вывода, такие 
как попытка записать в поврежденный блок диска или попытка прочитать данные 
с выключенной видеокамеры. В таких случаях драйвер сам решает, что ему делать. 
Если драйвер не может сам принять решение, он передает сведения о возникшей 
проблеме в вышестоящие инстанции (независимому от устройств программному 
обеспечению). 

Действия этого программного обеспечения зависят от окружения и природы 
ошибки. Если это простая ошибка чтения, а программа интерактивная, можно 
отобразить диалоговое окно с вопросом к пользователю о дальнейших действиях. 
В качестве выбора может быть предложено повторение попытки определенное 
число раз, игнорирование ошибки или уничтожение процесса. Если программа не 
интерактивная, единственная возможность состоит в аварийном завершении сис¬ 
темного вызова с соответствующим кодом ошибки. 

Однако не все ошибки могут быть обработаны подобным образом. Например, 
может оказаться поврежденной критическая структура данных, такая как корне¬ 
вой каталог или список свободных блоков. В этом случае, возможно, системе при¬ 
дется вывести сообщение об ошибке и завершить свою работу. 

Захват и освобождение выделенных устройств 

Некоторые устройства, например устройство записи компакт-дисков, могут ис¬ 
пользоваться в каждый момент времени только одним пользователем. Опера¬ 
ционная система должна рассмотреть запросы на использование этого устройства 
и либо принять их, либо отказать в выполнении запроса, в зависимости от доступ¬ 
ности запрашиваемого устройства. Простой способ обработки этих запросов со¬ 
стоит в требовании к процессам обращаться напрямую к системному вызову ореп 
по отношению к специальным файлам для данных устройств. Если устройство 
недоступно, системный вызов ореп завершится неуспешно. Обращение к систем¬ 
ному вызову сіозе освобождает устройство. 

Альтернативный подход состоит в предоставлении специального механизма 
для запроса и освобождения выделенных устройств. Попытка захватить недо¬ 
ступное устройство вызовет блокировку вызывающего процесса вместо возврата 
с ошибкой. Блокированные процессы устанавливаются в очередь. Раньше или 
позже запрашиваемое устройство освобождается и первому процессу в очереди 
разрешается захватить его и продолжить выполнение. 




Программные уровни ввода-вывода 


335 


Независимый от устройств размер блока 

У различных дисков могут быть разные размеры сектора. Независимое от устройств 
программное обеспечение должно скрывать этот факт от верхних уровней и предо¬ 
ставлять им единообразный размер блока, например, объединяя несколько физичес¬ 
ких сегментов в один логический блок. При этом более высокие уровни имеют дело 
только с абстрактными устройствами, с одним и тем же размером логического 
блока, не зависящим от размера физического сектора. Некоторые символьные 
устройства предоставляют свои данные побайтно (например, модемы), тогда как 
другие выдают их большими порциями (например, сетевые интерфейсы). Эти раз¬ 
личия также могут быть скрыты. 

Программное обеспечение ввода-вывода 
пространства пользователя 

Хотя большая часть программного обеспечения ввода-вывода находится в опера¬ 
ционной системе, небольшие его порции состоят из библиотек, присоединенных 
к программам пользователя, или даже целых программ, работающих вне ядра. Си¬ 
стемные вызовы, включая системные вызовы ввода-вывода, обычно состоят из 
библиотечных процедур. Если программа на С содержит вызов 

соипі - игНеШ, ЬиНег, пЬуЬез); 

библиотечная процедура хѵгііе будет скомпонована с программой и, таким образом, 
будет содержаться в двоичной программе, загружаемой в память во время выпол¬ 
нения программы. Набор всех этих библиотечных процедур, несомненно, являет¬ 
ся частью системы ввода-вывода. 

Хотя многие такие процедуры мало что делают, кроме обращения к системно¬ 
му вызову с соответствующими параметрами, есть ряд процедур ввода-вывода, 
выполняющих определенную работу. В частности, библиотечными процедурами 
выполняются операции форматного ввода и вывода. Например, процедура ргіпі :/ 
языка С, принимающая на входе текстовую строку и, возможно, несколько пере¬ 
менных, создает из нее А5СІІ-строку, после чего обращается к системному вызову 
игі^е для вывода строки. Для примера рассмотрим следующий оператор 

ргіпГГС'Квадрат числа %3сі равен *6сІ\п". і. і*і); 

Он форматирует строку, состоящую из 14-символьной строки "Квадрат числа", 
за которой следует значение переменной і в виде 3-символьной строки, затем 7-сим¬ 
вольной строки "равен", потом і 2 в виде 6 символов и, наконец, символа перевода 
строки. 

Примером сходной процедуры ввода может служить 5сап /, читающая текстовую 
строку и преобразующая ее в значения переменных в соответствии с форматом, 
сходным с используемым процедурой ргіпі/. Стандартная библиотека ввода-выво¬ 
да содержит большое количество процедур, включающих операции ввода-вывода 
и работающих как часть программы пользователя. 

Не все программное обеспечение ввода-вывода пространства пользователя со¬ 
стоит из библиотечных процедур. Другую важную категорию составляет система 
спулинга. Спулинг (зроо1іп§ — подкачка, предварительное накопление данных) 
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представляет собой способ работы с выделенными устройствами в многозадачной 
системе. Рассмотрим типичное устройство, на котором используется спулинг: 
принтер. В принципе можно разрешить каждому пользователю открывать специ¬ 
альный символьный файл принтера, однако представьте себе, что процесс открыл 
его, а затем не обращался к принтеру в течение нескольких часов. Ни один другой 
процесс в это время не сможет ничего напечатать. 

Вместо этого создается специальный процесс, называемый демоном, и специ¬ 
альный каталог, называемый каталогом спулинга или каталогом спулера. Чтобы 
распечатать файл, процесс сначала создает специальный файл, предназначенный 
для печати, который помещает в каталог спулинга. Этот файл печатает демон, 
единственный процесс, которому разрешается пользоваться специальным файлом 
принтера. Таким образом, потенциальная проблема, связанная с тем, что какой- 
либо процесс на слишком долгий срок захватит принтер, решается при помощи 
защиты специального файла принтера от прямого доступа пользователей. 

Спулинг используется не только для принтеров. Например, передачу файлов 
по сети также часто осуществляет специальный сетевой демон. Чтобы послать куда- 
либо файл, пользователь помещает его в каталог сетевого демона. Затем сетевой 
демон извлекает оттуда файл и посылает по сети. Подобный способ передачи фай¬ 
лов по сети используется системой сетевых новостей ИЗЕИЕТ Иеѵѵз. Эта сеть со¬ 
стоит из миллионов машин по всему миру, общающихся друг с другом по Интер¬ 
нету. Существуют тысячи конференций по самым разным темам. Чтобы послать 
новое сообщение, пользователь вызывает программу новостей, которая принима¬ 
ет сообщение, а затем помещает его в каталог спулинга для последующей переда¬ 
чи на другие машины. Вся система новостей работает вне операционной системы. 

На рис. 5.13 показана структура системы ввода-вывода, со всеми уровнями 
и основными функциями каждого уровня. Снизу вверх эти уровни представляют 
собой аппаратуру, обработчики прерываний, независимое от устройств программ¬ 
ное обеспечение и, наконец, процессы пользователя, 
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Рис. 5.13. Уровни и основные функции системы ввода-вывода 

Стрелки на рис. 5.13 изображают поток управления. Например, когда програм¬ 
ма пользователя пытается прочитать блок из файла, для обработки вызова запус- 
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кается операционная система. Независимое от устройств программное обеспече¬ 
ние ищет этот блок в кэше. Если требуемого блока там нет, оно вызывает драйвер 
устройства, чтобы обратиться к аппаратуре и получить этот блок с диска. При этом 
процесс блокируется до тех пор, пока не завершится дисковая операция. 

Когда диск завершает операцию, аппаратура инициирует прерывание. Обра¬ 
ботчик прерываний запускается, чтобы определить, что случилось, то есть какое 
устройство требует внимания. Затем он извлекает статус устройства и активизи¬ 
рует «спящий» процесс, чтобы завершить запрос ввода-вывода и предоставить 
пользовательскому процессу возможность продолжать. 


Диски 

Рассмотрим теперь некоторые реальные устройства ввода-вывода. Мы начнем 
с дисков. Затем мы также познакомимся с часами, клавиатурами и дисплеями. 

Аппаратная часть дисков 

Существует множество типов дисков. К наиболее часто встречающимся относят¬ 
ся магнитные диски (жесткие и гибкие). Их особенностью является одинаковая 
скорость чтения и записи, что делает их идеальными в качестве дополнительной 
памяти (страничная подкачка файлов, файловые системы и т. д.). Иногда, с целью 
создания высоконадежного устройства хранения, используются наборы жестких 
магнитных дисков. Для распространения программ, данных и фильмов исполь¬ 
зуются различные виды оптических дисков (СИ-КОМ, СИ-К, СЭ-КЛУ и ИѴИ). 
В следующих разделах мы сначала познакомимся с аппаратной частью, а затем 
с программным обеспечением для этих устройств. 

Магнитные диски 

Магнитные диски организованы в цилиндры, каждый из которых содержит столько 
дорожек, сколько есть у устройства головок, установленных вертикально. Дорож¬ 
ки делятся на секторы, их количество обычно варьируется от 8 до 32 у гибких дис¬ 
ков и до нескольких сот у жестких дисков. Число головок варьируется от 1 до 16. 

У некоторых магнитных дисков мало электроники, они предоставляют на вы¬ 
ходе простой поток битов. На этих дисках контроллер выполняет совсем немно¬ 
го работы. На других дисках, в частности на ШЕ-дисках (ШЕ, Іп1е§га1ес1 Эгіѵе 
Еіесігопісв — встроенный интерфейс накопителей), само устройство содержит мик¬ 
роконтроллер, выполняющий значительный объем работ, и позволяющий собствен¬ 
но контроллеру обращаться к нему с набором команд высокого уровня. 

ГОЕ-диски обладают одним свойством, обладающим важными последствиями 
для драйверов: контроллер способен выполнять одновременно поиск дорожки на 
двух и более дисках. Это свойство известно под названием перекрывающегося 
поиска. В то время как контроллер и программное обеспечение ожидают окончания 
операции поиска на одном устройстве, контроллер может инициировать поиск на 
другом устройстве. Многие контроллеры жестких дисков также могут совмещать 
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операцию чтения или записи на одном диске с поиском на другом или даже не¬ 
скольких дисках. Однако контроллеры гибких дисков не могут одновременно чи¬ 
тать и писать на двух дисководах. (Чтение или запись требует от контроллера пе¬ 
ремещения битов с максимальной скоростью, на которую он рассчитан, поэтому 
операция чтения или записи использует большую часть его вычислительных мощ¬ 
ностей.) В случае жестких дисков с их встроенными микроконтроллерами ситуа¬ 
ция радикально меняется, поэтому несколько жестких дисков могут одновремен¬ 
но работать в одной системе, по крайней мере переносить данные между диском 
и буфером контроллера. Однако между контроллером и оперативной памятью 
в каждый момент времени может происходить только одна операция по переносу 
данных. Способность одновременного выполнения двух или более дисковых опе¬ 
раций может существенно снизить среднее время доступа. 

В табл. 5.3 сравниваются параметры стандартного средства оригинального 
компьютера ІВМ РС с параметрами современного жесткого диска для демонстра¬ 
ции того, насколько сильно изменились магнитные диски за последние два деся¬ 
тилетия. Интересно отметить, что не все параметры улучшились в равной мере. 
Среднее время поиска дорожки улучшилось в семь раз, скорость передачи данных 
увеличилась в 1300 раз, тогда как емкость диска увеличилась в 50 000 раз. Это раз¬ 
личие вызвано относительно незначительными усовершенствованиями механи¬ 
ческой части по сравнению со значительно большим прогрессом в области увели¬ 
чения плотности записи. 


Таблица 5.3. Параметры 360-Кбайтного НГМД в сравнении с жестким диском 
ѴѴезІегп Ьідііаі \Л/І Э 18300 


Параметр 

НГМД ІВМ 360 Кбайт 

Жесткий диск ѴѴО 18300 

Количество цилиндров 

40 

10601 

Дорожек в цилиндре 

2 

12 

Секторов на дорожке 

9 

281 (среднее) 

Секторов на диске 

720 

35 742 000 

Байтов в секторе 

512 

512 

Емкость диска 

360 Кбайт 

18,3 Гбайт 

Время поиска (соседние цилиндры) 

6 мс 

0,8 мс 

Время поиска (среднее) 

77 мс 

6,9 мс 

Период обращения 

200 мс 

8,33 мс 

Время запуска/остановки двигателя 

250 мс 

20 с 

Время передачи 1 сектора 

22 мс 

17 мкс 


Глядя на спецификации современных жестких дисков, следует помнить, что 
указанная геометрия, используемая программным обеспечением драйвера, мо¬ 
жет отличаться от физического формата. На старых дисках число секторов на 
дорожке было одинаково на всех цилиндрах. Современные диски разделены на 
зоны с большим числом секторов на внешних дорожках и меньшим на внутрен¬ 
них. На рис. 5.14, а изображен крошечный диск с двумя зонами. На внешней зоне 
каждая дорожка состоит из 32 секторов, тогда как на внутренней зоне по 16 секто¬ 
ров на дорожке. Реальные диски, как, например, \ѴБ 18300, часто имеют по 16 зон 
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с числом секторов, увеличивающимся примерно на 4 % в каждой следующей зоне 
при движении от центра диска к краю. 



Рис. 5.14. Физическая геометрия диска с двумя зонами (а); возможная виртуальная 

геометрия этого диска (б) 


Чтобы не усложнять жизнь операционной системы излишними подробностя¬ 
ми, современные жесткие диски скрывают истинную геометрию и предоставляют 
в качестве интерфейса виртуальную геометрию с одинаковым числом секторов на 
всех цилиндрах. Встроенный микроконтроллер диска преобразует обращение к 
виртуальным цилиндру, головке и сектору в физические соответствующие пара¬ 
метры. Возможная виртуальная геометрия диска, изображенного на рис. 5.14, а, 
показана на рис. 5.14, б. В обоих случаях диск имеет 192 сектора. 

Для компьютеров с процессором Репііит максимальными значениями этих 
трех параметров часто являются значения 65 535, 16 и 63, что вызвано необходи¬ 
мостью обратной совместимости с ограничениями оригинальной машины ІВМ РС. 
На ней для хранения этих значений использовались 16-, 4- и 6-разрядные двоич¬ 
ные поля, причем номера цилиндров и секторов начинались с 1, а номера головок — 
с 0. При таких параметрах и 512 байтах на сектор максимальный размер поддер¬ 
живаемого диска равен 31,5 Гбайт. Чтобы преодолеть это ограничение, многими 
дисками теперь поддерживается режим ЬВА (Ъофсаі Віоск Асісігеввіп^ — логичес¬ 
кая адресация блоков), при котором секторы диска просто нумеруются последо¬ 
вательно начиная с 0, независимо от геометрии диска. 

ЯАЮ 

Производительность центральных процессоров за последнее десятилетие увели¬ 
чивалась экспоненциально, удваиваясь примерно каждые 18 месяцев. С произво¬ 
дительностью дисков дело обстояло совсем не так. В 70-е годы среднее время по¬ 
иска на дисках, используемых в мини-компьютерах, составляло от 50 до 100 мс. 
Сегодня время поиска немного ниже 10 мс. В большинстве отраслей промыш¬ 
ленности (например, в автомобильной или авиационной) увеличение производи- 
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тельности в 5 или 10 раз за два десятилетия считалось бы феноменальным, но в 
компьютерной промышленности такой низкий рост является препятствием. За эти 
годы разрыв между производительностью центрального процессора и производи¬ 
тельностью диска только еще более увеличился, причем весьма существенно. 

Как мы видели, для увеличения производительности центрального процессора 
все больше используются параллельные вычисления. На протяжении десятилетий 
идея распараллелить операции ввода-вывода также приходила в головы многих 
людей. В 1988 году в своей статье Паттерсон и его коллеги предложили шесть раз¬ 
личных способов организации дисков для улучшения производительности или 
надежности дисковых операций, либо и того и другого [261]. Эти идеи были быстро 
приняты промышленностью, в результате чего был разработан новый класс устройств 
ввода-вывода, названный КАШ. Паттерсон с соавторами определили КАГО как 
Кейипсіапі Аггау оГ Іпехрепзіѵе Эізкз — массив недорогих дисков с избыточностью, 
но промышленники переопределили букву I как «Іпс1ерепс1епР> (независимые). Воз¬ 
можно, это должно было им позволить продавать диски по высоким ценам. По¬ 
скольку в этой пьесе также требовался кто-нибудь на роль злодея (как и в случае 
противостояния КІ5С и СІ5С, также благодаря Паттерсону), «негодяя» назвали 
8ЫШ (5іп§1е Ьаг§е Ехрепзіѵе Эізк — одиночный большой и дорогой дисковый 
накопитель). 

Идея, лежащая в основе системы КАГО, состоит в том, что на компьютер (обыч¬ 
но большой сервер) устанавливается коробка, полная дисков. Вместо обычного дис¬ 
кового контролера устанавливается специальный КАГО-контроллер, а весь набор 
дисков выглядит с точки зрения операционной системы как один большой (и доро¬ 
гой) дисковый накопитель, то есть ЗЬЕО, но обладает более высокой производи¬ 
тельностью и большей надежностью. Поскольку 5С5І-диски отличаются высокой 
производительностью, низкой ценой и способны работать до 7 штук на одном кон¬ 
троллере (до 15 для так называемого «широкого» 5С5І), неудивительно, что боль¬ 
шинство КАШ-систем состоят из КАГО-контроллера 5С5І и коробки 5С5І-дисков. 
Операционная система воспринимает их как один большой диск. Таким образом, 
для использования системы КАГО не требуется никаких изменений программно¬ 
го обеспечения, что является большим плюсом с точки зрения системных админи¬ 
страторов. 

Еще одно свойство всех КАШ-систем состоит в том, что данные распределя¬ 
ются по дискам, а это позволяет распараллеливать операции. Паттерсоном и его 
коллегами было предложено несколько различных схем использования системы 
КАГО, получивших известность как уровни от нулевого до пятого. Помимо них 
существует еще несколько второстепенных уровней, которые мы не станем здесь 
обсуждать. Употребление термина «уровень» не совсем правильно в этом случае, 
так как данные схемы использования системы КАГО не образуют иерархии. Есть 
просто шесть различных вариантов организации совместной работы дисков. 

Система КАГО уровня 0 проиллюстрирована на рис. 5.15, а. Она рассматрива¬ 
ет единый виртуальный диск, эмулируемый контроллером КАГО, как разбитый на 
полосы, состоящие из одинакового числа секторов (обычно по 64 Кбайт), пере¬ 
секающие наборы дисков так, что первый блок секторов записывается на пер¬ 
вый диск, второй блок — на второй диск и т. д. по кругу. На рис. 5.15, я показана 
система КАГО уровня 0 для четырех дисков. Подобный способ хранения данных 




Диски 


341 


на нескольких дисках называется чередующимся набором. При этом, если про¬ 
грамма издает запрос чтения или записи целой полосы данных, Я А [ О- контроллер 
разбивает этот запрос на отдельные запросы по числу дисков и адресует каждый 
запрос отдельному диску. Таким образом, все диски системы КАШ работают па¬ 
раллельно, причем программное обеспечение об этом может даже не догадывать¬ 
ся. Восстановление вышедшего из строя диска в этом случае будет значительно 
сложнее, чем в системе КАШ уровня 4 1 . 

Система КАШ уровня 0 лучше всего работает с большими запросами, что есте¬ 
ственно, так как при этом работа более равномерно распределяется между диска¬ 
ми. В результате производительность такой системы оказывается достаточно вы¬ 
сокой при довольно простой реализации. 

Хуже всего система КАШ уровня 0 работает с операционными системами, име¬ 
ющими привычку запрашивать данные по одному сектору. Запрос будет выполнен 
верно, но параллельной загрузки дисков при этом не получится и, соответствен¬ 
но, не будет и выигрыша в производительности. Еще один недостаток системы 
КАШ уровня 0 заключается в том, что надежность такой системы потенциально 
ниже, чем у одного диска (5ЬЕВ). Так, если система КАШ состоит из четырех дис¬ 
ков со средней наработкой на отказ для каждого диска, равной 20 000 часов, то при 
совместном использовании этих дисков примерно раз в 5000 часов один из дисков 
будет отказывать, что приведет к отказу всей системы КАШ. Причем в этом слу¬ 
чае могут быть потеряны все данные. Таким образом, получается, что 5ЬЕО ока¬ 
зывается в четыре раза надежнее. Поскольку в системе КАШ уровня 0 избыточ¬ 
ность не предусмотрена, она не считается настоящей КАШ-системой. 

Следующий вариант, КАШ уровня 1, показанный на рис. 5.15, б, представляет 
собой настоящую систему КАШ. В ней дублируются все диски, в результате име¬ 
ются четыре основных и четыре резервных диска. Такая система КАШ называется 
также зеркальным набором. При записи каждая полоса записывается дважды. При 
чтении может использоваться любая копия. Таким образом, по сравнению с систе¬ 
мой КАШ уровня 0 скорость записи не увеличивается, а чтение может быть уско¬ 
рено вдвое. Отказоустойчивость такой системы очень хороша, так как все данные 
дублируются полностью. Для восстановления системы при выходе из строя одного 
из дисков нужно всего лишь заменить диск и скопировать на него данные с диска- 
копии. Недостатком является снижение используемой общей емкости дисков вдвое. 

В отличие от уровней 0 и 1, работающих с полосами и секторами, система КАЮ 
уровня 2 работает на уровне слов и даже байтов. Представьте разбиение каждого 
байта единого виртуального диска на пару 4-битовых полубайтов, затем добавле¬ 
ние к каждому из них кода Хэмминга с образованием 7-битового слова, в котором 
биты 1, 2 и 4 являются битами четности. Затем представьте, что семь дисков на 
рис. 5.15, в синхронизированы по скорости вращения и позиции головок. В этом 
случае будет возможно записать закодированное по Хэммингу 7-битовое слово на 
семь дисков, по биту на диск. 

1 Точнее, процесс восстановления абсолютно ничем не отличается от предыдущего случая. В обоих 
случаях нужно всего лишь сложить все данные на оставшихся дисках но модулю 2, что обусловлива¬ 
ется природой этой арифметической операции, являющейся обратной для самой себя. Немного слож¬ 
нее для системы будет лишь процесс обычной записи на КАШ уровня 5. — Примеч. перед. 
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КАЮ уровень О 
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Рис. 5.15. Системы КАЮ уровней от 0 до 5. Резервные диски затенены 
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Эта схема использовалась в компьютере СМ-2 фирмы ТЬіпкіп§ МасЬіпез. 
Бралось 32-разрядное слово данных, к нему добавлялись 6 битов четности, чтобы 
образовать 38-разрядное слово Хэмминга, плюс дополнительный бит четности. По¬ 
лученное 39-разрядное слово записывалось на 39 дисков. Таким образом, скорость 
операций чтения и записи увеличивалась в 32 раза. Потеря одного из устройств 
также не вызывала особых проблем, поскольку это приводило к потере всего одного 
бита в 39-разрядном слове, с чем код Хэмминга легко справлялся на лету. 

Недостаток этой схемы заключался в том, что для ее работы требовалась синх¬ 
ронизация вращения всех дисков. Кроме того, такая схема имела смысл только при 
значительном количестве дисков. Даже при 32 дисков с данными и 6 с битами чет¬ 
ности накладные расходы составляли 19 %. Кроме того, контроллер должен посто¬ 
янно и с большой скоростью считать контрольную сумму по Хэммингу. 

Система КАШ уровня 3 представляет собой упрощенную версию системы 
КАШ уровня 2. Одна показана на рис. 5.15, г. В этой схеме для каждого слова дан¬ 
ных считается один бит четности, записываемый на отдельный диск четности. Как 
и в случае системы КАШ уровня 2, все диски должны быть точно синхронизиро¬ 
ваны, так как слово данных побитно пишется сразу на все диски. 

На первый взгляд может показаться, что одиночный бит четности дает только 
возможность выявления ошибок, но не их исправления. Для случайных ошибок 
в произвольном разряде это справедливо. Однако для случая выхода из строя дис¬ 
ка одного бита вполне достаточно для полного восстановления данных, так как по¬ 
зиция бита известна. В случае выхода диска из строя контроллер просто считает, 
что все биты, содержащиеся на нем, равны нулю, определяя их истинное значение 
по четности разрядов, считанных с остальных дисков. Хотя оба уровня 2 и 3 систе¬ 
мы КАШ позволяют добиться очень высоких скоростей передачи данных, число 
отдельных запросов ввода-вывода, которые они могут обработать, не выше, чем 
у отдельного диска. 

Системы КАШ уровней 4 и 5 снова работают с полосами (чередующимися на¬ 
борами данных), а не с отдельными словами с битами четности, поэтому не требу¬ 
ют синхронизации дисков. Система КАШ уровня 4 (рис. 5.15, д ) аналогична уров¬ 
ню 0, но с дополнительным диском четности, содержащим сумму по модулю два 
всех данных с остальных дисков. Если любой из дисков выйдет из строя, поте¬ 
рянные байты могут быть восстановлены при помощи той же операции сложения 
по модулю два. 

Такая организация надежно защищает от выхода диска из строя, но при не¬ 
больших изменениях информации, хранящейся на дисках, производительность не 
только не увеличивается, а даже наоборот, снижается. Если изменяется всего один 
сектор, то все равно необходимо прочитать данные со всех дисков, чтобы заново 
рассчитать значения битов четности, которые нужно будет перезаписать. В каче¬ 
стве альтернативы можно читать старые данные пользователя и старое значение 
избыточной информации и пересчитывать новое значение по этим данным. Но и 
такой вариант все равно требует дополнительных операций чтения перед опера¬ 
циями записи. 

В результате повышенной нагрузки на диск, содержащей избыточные данные, 
этот диск может стать узким местом системы. Эта проблема решается в системе 
КАШ уровня 5, в которой биты четности равномерно распределены по всем дискам, 
как показано на рис. 5.15, е. На первый взгляд может показаться, что восстановле- 
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ние вышедшего из строя диска в этом случае будет значительно сложнее, чем в сис¬ 
теме КАШ уровня 4. Однако на самом деле оно ничем не отличается от предыдуще¬ 
го случая. В обоих случаях нужно всего лишь сложить все данные на оставшихся 
дисках по модулю 2, что обусловливается природой этой арифметической опера¬ 
ции, являющейся обратной для самой себя. 

Компакт-диски 

В 70-е годы появились оптические диски (в противоположность магнитным). Их 
плотность записи сразу значительно превзошла плотность записи магнитных дис¬ 
ков. Изначально оптические диски были разработаны для записи телевизионных 
программ, но затем для них были придуманы другие сферы применения, в том 
числе хранение компьютерных данных. Благодаря их потенциально огромной 
емкости, оптические диски стали предметом большого числа исследований и со¬ 
вершили невероятно быструю эволюцию. 

Оптические диски первого поколения были разработаны голландским элект¬ 
ронно-промышленным конгломератом РЬШрз для хранения фильмов. Они были 
30 см в диаметре и продавались на рынке под названием ЬазегѴізіоп, но без особо¬ 
го коммерческого успеха, разве что в Японии. 

В 1980 году фирма РЬШрз совместно с 8опу разработала компакт-диск (СБ, 
Сошрасі Віяс), который быстро вытеснил вращающиеся со скоростью 33 1 /3 оборо¬ 
тов в минуту виниловые пластинки (хотя до сих пор отдельные люди, называющие 
себя «аудиофилами», утверждают, что качество звука у винилов выше, чем у лазер¬ 
ных компакт-дисков). Точные технические детали компакт-диска были опублико¬ 
ваны в виде Международного стандарта 18 10149, называемого в народе Красной 
книгой из-за цвета обложки. Международные стандарты издаются Международной 
организацией по стандартизации 180 (Іпіегпаііопаі Ог^апшйіоп Іог Зіаініагсіігаііоп). 
Каждому международному стандарту обычно соответствует какой-либо нацио¬ 
нальный стандарт, как, например, АЫ8І (Ашегісап Шііопаі Зіапсіагсіз Іпзіііиіе — 
Национальный институт стандартизации США) или ОШ (БеиІзсЬе Іпбизігіе 
Иогт — промышленная норма Германии), применяемые в Европе. Публикация 
спецификаций компакт-диска в качестве международного стандарта обеспечи¬ 
вает совместную работу компакт-дисков и проигрывателей для них, выпущенных 
производителями всего мира. Все компакт-диски должны иметь диаметр 120 мм 
и толщину 1,2 мм, с 15-мм отверстием в середине. Аудиокомпакт-диски стали пер¬ 
вым цифровым носителем, завоевавшим успех на массовом рынке. Предполагается, 
что они будут сохраняться до 100 лет. Пожалуйста, проверьте в 2080 году, так ли это. 

Для производства компакт-дисков используется мощный инфракрасный лазер, 
которым прожигаются отверстия диаметром 0,8 мкм в металлическом покры¬ 
тии стеклянного диска-оригинала, называемого также мастер-диском. С мастер¬ 
диска снимается слепок с выпуклостями на месте прожженных лазером отверстий. 
С помощью этого слепка из поликарбонатной смолы печатаются компакт-диски 
с тем же рисунком выемок, что и на стеклянном оригинале. Затем застывший по¬ 
ликарбонат покрывается очень тонким слоем отражающего свет алюминия, поверх 
которого диск покрывается защитным лаком, а на него затем наносится этикет¬ 
ка. Углубления в поликарбонате называют питами (ріі — впадина), а нетронутые 
лазером участки между питами называют «землей» или «сушей» (Іапсі). 
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При воспроизведении полупроводниковый лазер низкой мощности освещает 
питы и участки между ними лучом с длиной волны 0,78 мкм, в то время как они 
прокручиваются с постоянной линейной скоростью. Лазер освещает алюминиевое 
покрытие диска сквозь прозрачный поликарбонатный диск толщиной в 1,2 мм. Питы 
выглядят с этой стороны как выступы высотой в четверть длины волны луча лазера. 
В результате интерференции свет, отраженный от питов, имеет меньшую яркость, 
чем отраженный от участков между ними, что и регистрируется фотодетектором 
как последовательность нулей и единиц. На самом деле для большей надежности 
за 1 считается переход пит/земля или земля/пит, а отсутствие перехода означает 0. 

Последовательность питов и промежутков между ними записывается в виде 
единой непрерывной спиральной дорожки, начинающейся недалеко от центра дис¬ 
ка и заканчивающейся у края диска. Максимальная ширина спирали может состав¬ 
лять 32 мм, а число оборотов — 22 188 (около 600 на мм). Длина спирали, показан¬ 
ной на рис. 5.16, достигает 5,6 км в длину. 



Чтобы музыка воспроизводилась с постоянной скоростью, поток питов и про¬ 
межутков между ними должен двигаться под лучом лазера с постоянной линей¬ 
ной скоростью в 120см/с. Соответственно, по мере продвижения считывающей 
головки от центра диска к краю, угловая скорость вращения компакт-диска должна 
постоянно уменьшаться от 530 об/мин до 200 об/мин. В этом принципиальное 
отличие оптических дисков от магнитных, вращающихся с постоянной угловой ско¬ 
ростью, не зависящей от текущего положения головок 1 . Кроме того, 530 об/мин — 
это существенно меньше, чем 3600 об/мин или 7200 об/мин, типичная скорость 
вращения магнитных дисков. 

В 1984 году фирмы РЬШря и Зопу осознали потенциал использования компакт- 
дисков для хранения компьютерных данных, поэтому они опубликовали Желтую 


1 Требование постоянной линейной скорости значительно усложняет механизм и требует постоянных 
затрат энергии и времени на разгон и торможение диска. — Примеч. перво. 
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книгу, в которой определили точный стандарт того, что теперь называется СО¬ 
КОМ (Сошрасі Оізк Кеасі Опіу Мешогу — компакт-дисковое постоянное запоми¬ 
нающее устройство). Поскольку ранок аудиокомпакт-дисков к тому моменту был 
уже весьма широк, было решено сделать СО-КОМ точно того же размера, что 
и аудиокомпакт-диски, а также механически и оптически совместимыми с ними. 
Помимо возможности проигрывать музыку на устройствах чтения СО-КОМ, это 
также давало возможность использовать для производства СО-КОМ те же техно¬ 
логические линии, на которых производились аудиокомпакт-диски. В результате 
себестоимость производства одного СО-КОМ оказалась намного ниже одного 
доллара. Недостатком такого решения явилась необходимость использования 
в устройствах чтения СО-КОМ медленных двигателей, вращающихся с перемен¬ 
ной скоростью. 

В Желтой книге был определен формат компьютерных данных. Новый стан¬ 
дарт также улучшал способность системы исправлять ошибки, что было очень важ¬ 
но, так как если на слух почти не заметно искажение одного бита то тут то там, для 
хранения компьютерной информации требуется значительно более высокая на¬ 
дежность. Основой формата СО-КОМ является кодирование одного байта 14-раз- 
рядным числом. Как уже было сказано, 14 разрядов достаточно для кодирования 
одного байта (8 бит) кодом Хэмминга с запасом в два бита. В действительности 
используется более мощная система помехоустойчивого кодирования. При чтении 
преобразование 14-В-8 осуществляется аппаратно при помощи таблицы. 

На более высоком уровне группа из 42 последовательных 14-разрядных сим¬ 
волов образуют 588-разрядный кадр. Каждый кадр содержит 192 бит данных 
(24 байт). Оставшиеся 396 бит используются для коррекции ошибок и управле¬ 
ния. До сих пор используемая схема одинакова для звуковых компакт-дисков 
иСБ-КОМ. 

Желтая книга добавляет к этому стандарту группирование 98 кадров в так 
называемый СО-КОМ-сектор, как показано на рис. 5.17. Каждый СО-КОМ- 
сектор начинается 16-байтовым заголовком, первые 12 байт которого содержат 
ООРРРРРРЕРРРРРРРРРРРРРОО (шестнадцатеричное), чтобы считывающее устрой¬ 
ство могло распознать начало СО-КОМ-сектора. Следующие три байта содержат 
номер сектора, что необходимо, так как поиск данных на единственной спирали 
диска значительно сложнее, чем на магнитном диске, состоящем из концентричес¬ 
ких дорожек. При поиске программное обеспечение устройства приблизительно 
вычисляет, куда переместить головку, а после перемещения головки считывает 
первый заголовок, проверяя, насколько точно удалось приблизиться к требуемым 
данным. Последний байт заголовка содержит код режима. 

Желтой книгой определяется два режима. В режиме 1 используется формат, 
показанный на рис. 5.17, с 16-байтовым заголовком, 2048 байт данных и 288-бай¬ 
товым кодом исправления ошибок ЕСС (Еггог Соггесііоп Собе), для которого 
используется перемежающийся код Рида—Соломона. В режиме 2 поле данных 
объединяется с полем ЕСС в 2336-байтное поле данных. Этот режим может ис¬ 
пользоваться для тех приложений, которым не требуется (или у них нет на это 
времени) коррекция ошибок, например аудио или видео. Обратите внимание, что 
коррекция ошибок осуществляется на трех уровнях: внутри символа, в кадре и в СО- 
КОМ-секторе. Однобитовые ошибки исправляются на нижнем уровне, короткие 
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пакеты ошибок корректируются на уровне кадров, а все остальные ловятся на 
уровне сектора. В результате 98 кадров по 588 бит (7203 байт) содержат всего 
лишь 2048 байт полезной нагрузки, что соответствует эффективности около 28 %. 
Такую цену приходится платить за надежность хранения информации на опти¬ 
ческом диске. 

ооо ••• ооо Символы по 14бит 


оооооооо 


42 символа составляют 1 кадр 

Кадры по 588 бит 

оооооооов каждом, содержащие 


Заголовок 

А— 


98 кадров составляют 1 сектор 


Данные 


ЕСС 


по 24 байт данных 


Сектор режима 1 
(2352 байт) 


Байты 16 2048 288 

Рис. 5.17. Логическое расположение данных на СР-ВОМ 


Односкоростные СО-КОМ-приводы считывают данные со скоростью 75 сек¬ 
торов в секунду, что соответствует скорости передачи данных 153 600 байт/с в ре¬ 
жиме 1 и 175 200 байт/с в режиме 2. Двухскоростные приводы в два раза быстрее 
и т. д. Таким образом, 40-скоростной СО-КОМ-привод может поставлять данные 
со скоростью до 40x153 600 байт/с (6000 Кбайт/с), при условии, что интерфейс 
устройства, шина и операционная система могут обработать такой поток данных. 
На стандартном аудиокомпакт-диске помещается до 74 мин музыки, что при ис¬ 
пользовании его для хранения данных в режиме 1 дает емкость в 681 984 000 байт. 
Эта величина обычно обозначается как 650 Мбайт, так как 1 Мбайт равен 2 20 байт 
(1 048 576 байт), а не 1 000 000 байт. 

Обратите внимание, что даже 32-скоростное устройство чтения СО-КОМ 
(4 915 200 байт/с) не ровня магнитному диску 5С5І-2 со скоростью в 10 Мбайт/с, 
несмотря на то что во многих СО-КОМ-приводах используется интерфейс 5С5І 
(ШЕ СО-КОМ-приводы также существуют). Если задуматься о времени поиска 
для устройств чтения СО-КОМ, составляющем несколько сот миллисекунд, ста¬ 
нет ясно, что по производительности эти устройства находятся совсем не в той 
«весовой» категории, где жесткие магнитные диски, несмотря на довольно внуши¬ 
тельную емкость. 

В 1986 году фирма РЬіІірз снова нанесла удар, выпустив Зеленую книгу, доба¬ 
вив к стандарту графику и возможность совмещения в одном секторе аудио, видео 
и данных, что существенно для мультимедийных компакт-дисков. 

Наконец, следует рассмотреть файловую систему, используемую на СО-КОМ. 
Чтобы один и тот же СО-КОМ можно было использовать на различных компьюте¬ 
рах, необходимо добиться соглашения по вопросу файловых систем для СО-КОМ. 
Для достижения этого соглашения представители многих компьютерных компа¬ 
ний встретились на озере Тахо, в Хай Сьеррас, на границе Калифорнии и Невады. 
По названию местности была названа разработанная ими файловая система Ні§Ь 
5іегга. Позднее она была оформлена в виде Международного стандарта 18 9660. 
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Файловая система №§Ь Зіегга состоит из трех уровней. На первом уровне файлы 
имеют имена формата, схожего с М5-Э05 — до 8 символов имя файла плюс до 
3 символов расширение. В имени файла могут использоваться только прописные 
символы, цифры и символ подчеркивания. Глубина вложенности каталогов огра¬ 
ничена восемью. Имена каталогов не могут содержать расширений. Все файлы 
уровня 1 должны быть непрерывными, чего не сложно добиться на носителе, 
на который информация записывается всего один раз. Таким образом, любой 
СИ-КОМ, соответствующий уровню 1 стандарта 15 9660, может быть прочитан 
в системе М5-И05, на компьютере Арріе, в системе ІШІХ, то есть практически на 
любом компьютере. Производители СИ-КОМ считают это свойство большим 
плюсом. 

Уровень 2 стандарта 15 9660 разрешает использовать имена файлов длиной до 
32 символов, а уровень 3 позволяет использовать сегментированные файлы. 
Расширения стандарта Коек Кіс1§е (прихотливо названное в честь города в филь¬ 
ме Джина Уайлдера Віагіщ Засісііез) разрешают использовать очень длинные 
имена (для ІЛЧІХ), а также универсальные идентификаторы ШИ, глобальные 
идентификаторы СІИ и связывание файлов. Однако СИ-КОМ, не удовлетворя¬ 
ющие уровню 1 стандарта 15 9660, моіут оказаться нечитаемыми на многих компь¬ 
ютерах. 

СИ-КОМ становятся все более популярными для распространения игр, филь¬ 
мов, энциклопедий, атласов, учебников и т. п. Большая часть коммерческого про¬ 
граммного обеспечения сегодня распространяется на СИ-КОМ. Благодаря соче¬ 
танию большой емкости и низкой цены СИ-КОМ удачно подходят для самых 
разнообразных приложений. 

Компакт-диски с возможностью записи 

Сначала оборудование, необходимое для создания СИ-КОМ (или аудиокомпакт- 
диска), было крайне дорогим. Но как это обычно бывает в компьютерной промыш¬ 
ленности, ничто не остается дорогим надолго. К середине 90-х годов устройства 
для записи компакт-дисков размером не более проигрывателей компакт-дисков 
стали обычными периферийными устройствами, продающимися в большинстве 
компьютерных магазинов. Эти устройства по-прежнему отличались от магнитных 
дисков, так как позволяли только один раз записывать данные, которые потом 
было нельзя стереть. Тем не менее они быстро нашли свою нишу в качестве но¬ 
сителей для резервных копий больших жестких дисков, а также позволили отдель¬ 
ным пользователям или небольшим компаниям производить свои небольшие 
серии СЭ-КОМ или создавать оригиналы-макеты для доставки их на коммерчес¬ 
кие фабрики по производству компакт-дисков. Эти носители известны под назва¬ 
нием СЭ-К (СЭ-КесогсІаЫе — компакт-диски с возможностью записи). 

Физически компакт-диски с возможностью записи, так же как и обычные 
СЭ-КОМ, состоят из 120-мм поликарбонатных пластин, с той разницей, что на них 
нанесена спиральная дорожка глубиной 0,6 мм для направления луча лазера при 
записи. Дорожка выполнена в виде синусоиды с амплитудой в 0,3 мм и частотой 
22,05 кГц (при одинарной скорости вращения диска), что обеспечивает постоян¬ 
ную обратную связь, позволяющую отслеживать и корректировать скорость 
вращения диска. СЭ-К выглядят как обычные СЭ-КОМ, отличаясь от них в основ- 
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ном этикеткой и цветом. С верхней стороны СБ- К золотые, в отличие от серебри¬ 
стых обычных компакт-дисков. Этот цвет вас не обманывает. Это действительно 
тонкий слой золота, используемый для отражения луча лазера вместо алюминия. 
В отличие от обычных серебристых компакт-дисков, на поверхности которых 
пресс-формой нанесены углубления, на СБ-К-дисках отличия в отражающей 
способности питов и промежутков между ними должны имитироваться другим 
способом. Это достигается при помощи добавления специального слоя красителя 
между поликарбонатом и отражающей золотой поверхностью, как показано на 
рис. 5.18. Используются два типа красителя: синевато-зеленый цианин и желто¬ 
вато-оранжевый фталоцианин. Химики могут спорить до хрипоты, доказывая пре¬ 
имущества одного красителя над другим. Эти красители сходны с используемыми 
в фотографии, что объясняет, почему корпорации Еазітап Косіак и Ецр являются 
основными производителями чистых СБ-В. 


1,2 мм 




Этикетка 


Направление 

движения 


Фотодетектор 




Г 


7 




_ 


-Линза 


- Призма 


Инфракрасный 
лазерный диод 


Защитный лак 

Отражающее золотое покрытие 

М | | Слой красителя 

іи шг 

Полуотра: 

кающий слой 


Темное пятно в слое 
красителя, прожженное 
' лазером при записи 


Рис. 5.18. Поперечный разрез СР-Й и лазера (не в масштабе). Серебристые СР-ЙОМ 
имеют сходную структуру с той разницей, что у них нет слоя красителя, а вместо 
золотого покрытия — алюминиевое с углублениями 

В изначальном состоянии уровень красителя прозрачен и позволяет лучу лазе¬ 
ра проходить сквозь него и отражаться от золотого покрытия. Во время записи 
лазер переводится в режим высокой мощности (8-16 мВт). Когда луч лазера попа¬ 
дает на краситель, он нагревает его, разрушая химические связи. При этом образу¬ 
ется темное пятно. При чтении лучом лазера с мощностью 0,5 мВт фотодетектор 
замечает разницу между темными пятнами, прожженными лазером, и нетронутыми 
прозрачными областями. Это различие интерпретируется так же, как и разница меж¬ 
ду выемками и ровной поверхностью у обычных компакт-дисков, даже на обычных 
устройствах чтения СБ-КОМ и проигрывателях аудиокомпакт-дисков. 

Ни одна новая разновидность компакт-дисков не может обойтись без книги 
соответствующего цвета, поэтому в 1989 году была опубликована Оранжевая 
книга, посвященная компакт-дискам с возможностью записи. Этот документ онре- 
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деляет формат СБ-К, а также новый формат, СБ-КОМ ХА, позволяющий посек- 
торно дописывать информацию на СБ-К. Группа последовательных секторов, за¬ 
писываемых за один раз, называется СБ-КОМ-дорожкой. 

Одним из первых применений СБ-К была система Кобак РЬоіоСБ, в которой 
диск использовался в качестве фотоальбома. Клиент приносил отснятую фото¬ 
пленку и свой старый РЬоІоСБ в киоск фирмы Косіак и получал обратно тот же 
самый диск с дописанными на него новыми фотографиями. Новый пакет фото¬ 
графий, созданных при сканировании негативов, записывается на РЬоіоСБ в виде 
отдельной С В - КО М-дорожки. Инкрементная запись требовалась, так как в момент 
появления первых СБ-К на рынке их цена была слишком высока, чтобы исполь¬ 
зовать в качестве одноразового носителя. 

Однако инкрементная запись создает новую проблему. До выхода в свет Оран¬ 
жевой книги у всех СБ-КОМ было единое оглавление тома ѴТОС (Ѵоіише ТаЫе 
оі’ Сопіепіз) в начале диска. При использовании инкрементной (многодорожеч¬ 
ной) записи такая схема перестает работать. Решение, опубликованное в Оранже¬ 
вой книге, состоит в том, что для каждой СБ-КОМ-дорожки создается собствен¬ 
ное оглавление тома ѴТОС. В нем могут перечисляться некоторые или все файлы 
предыдущих дорожек. Когда СБ-К вставляется в дисковод, операционная систе¬ 
ма перебирает все СБ-КОМ-дорожки в поисках самого последнего оглавления 
тома, соответствующего текущему состоянию диска. Включением в новое оглавле¬ 
ние тома не всех файлов из предыдущего оглавления создается иллюзия удаления 
файлов с диска. Дорожки могут объединяться в сеансы, образуя диски с многосе¬ 
ансовой записью. Стандартные проигрыватели компакт-дисков не поддерживают 
многосеансовые компакт-диски, так как они рассчитаны на единственное оглав¬ 
ление тома в начале диска. 

Каждая дорожка должна быть записана на диск за одну непрерывную (без ос¬ 
тановок) операцию. В результате жесткий диск, с которого производится запись, 
должен быть достаточно быстрым, чтобы успевать предоставлять записываемые 
данные вовремя. Если копируемые на диск файлы разбросаны по всему жесткому 
диску, время поиска может оказаться слишком долгим, что приведет к опустоше¬ 
нию буфера и «пересыханию» потока данных, поступающих на СБ-К. В результа¬ 
те вместо диска с записями вы получите блестящую (но несколько дороговатую) 
подставку под стаканы для прохладительных (или горячительных) напитков, 
которая также неплохо летает. Программное обеспечение для устройств записи 
СБ-К обычно предлагает собрать все записываемые файлы в виде единого непре¬ 
рывного образа СБ-КОМ, размером в 650 Мбайт, прежде чем прожигать СБ-К, 
но эта процедура удваивает общее время записи диска и требует 650 Мбайт сво¬ 
бодного места на жестком диске. К тому же даже такая мера не спасает от случай¬ 
ностей, как, например, перегрев жесткого диска, в результате которого он вдруг 
начинает выполнять операцию термальной калибровки. 

Компакт-диски с возможностью записи упрощают отдельным пользователям 
и компаниям задачу перезаписи СБ-КОМ и аудиокомпакт-дисков, обычно нарушая 
авторские права издателя оригинального диска. Для усложнения жизни пиратов 
были разработаны различные схемы, в частности усложняющие чтение СБ-КОМ 
чем-либо, не являющимся программным обеспечением издателя. Одна из таких 
схем заключается в указывании фиктивной многогигабайтной длины файлов, что 
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усложняет копирование файлов на жесткий диск при помощи стандартных про¬ 
граммных средств. Истинные длины файлов упрятаны в программном обеспечении 
издателя или в неожиданном месте компакт-диска, возможно, в зашифрованном 
виде. Другая схема заключается в использовании намеренно неверной ЕСС-ин- 
формации в некоторых секторах в расчете на то, что программное обеспечение, 
копирующее компакт-диск, «исправит» эти ошибки. Программное обеспечение 
издателя само проверяет коды исправления ошибок, и если они верны, то отка¬ 
зывается работать. Также возможно использование нестандартных промежутков 
между дорожками и других физических «дефектов». 

Многократно перезаписываемые компакт-диски 

Хотя люди привыкли пользоваться носителями, позволяющими однократную 
запись, такими как бумага или фотопленка, спрос на СБ-К.ОМ с возможностью 
многократной перезаписи оставался. Такая технология недавно появилась под 
названием СО-КЛѴ (СБ-Ке\Ѵгі1:аЫе — многократно перезаписываемые компакт- 
диски). СБ-КЛѴ по размерам ничем не отличаются от обычных компакт-дисков, 
СВ-КОМ или СВ-К. Однако вместо цианина или фталоцианина в СВ-КѴѴ в каче¬ 
стве записывающего слоя используется сплав серебра, индия, сурьмы и теллура. 
У этого сплава два устойчивых состояния: кристаллический и аморфный, с раз¬ 
личной отражающей способностью. 

В устройствах записи СБ-КЛУ используются лазеры с тремя различными уров¬ 
нями мощности. При высокой мощности лазер расплавляет сплав, преобразуя его 
из кристаллического состояния с высокой отражающей способностью в аморфное 
состояние с низкой отражающей способностью, соответствующее питу. При сред¬ 
ней мощности лазер плавит сплав, превращая его в кристаллическое состояние, 
соответствующее промежуткам между питами. При низкой мощности лазер считы¬ 
вает информацию с диска, не вызывая фазовых переходов сплава. 

Причина, по которой СВ-КЛУ не вытеснили с рынка СВ-К, заключается в их 
значительно более высокой цене. Кроме того, для архивирования жестких дисков 
невозможность случайно стереть СБ-К. является большим плюсом. 

эѵэ 

Базовый формат компакт-дисков (СВ/СВ-КОМ) не менялся с 1980 года. Одна¬ 
ко технология с тех пор ушла вперед, в результате чего стало экономически воз¬ 
можным создание оптических дисков большей емкости. Спрос на такие диски уже 
весьма велик и продолжает возрастать. Голливуд хотел бы заменить видеоленты 
цифровыми дисками, поскольку диски обеспечивают более высокое качество изоб¬ 
ражения, дешевле в производстве, долговечнее, занимают меньше места на полках 
магазинов и не требуют перемотки. Компании, занимающиеся производством 
электронных потребительских товаров, ищут новый продукт, который бы вызвал 
очередной покупательский бум, а различные компьютерные компании мечтают 
добавить к своему программному обеспечению черты мультимедиа. 

В результате объединения технологических усилий и интересов трех бога¬ 
тейших и мощнейших отраслей промышленности и была создана система ОѴО. 
Сокращение ВѴБ, изначально расшифровывающееся как Віфіаі Ѵійео Візк (циф- 
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ровой видеодиск), теперь официально обозначает Бі§іІа1 Ѵегзаіііе Бізк (универ¬ 
сальный цифровой диск). В БѴБ используется та же самая общая схема, что и для 
компакт-дисков, то есть те же 120-мм поликарбонатные диски, изготавливаемые 
печатным способом, содержащие углубления, освещаемые лазером и считываемые 
фотодетектором. Новым для БѴБ было: 

1. Вдвое меньший размер питов (0,4 мкм против 0,8 мкм для компакт-дисков). 

2. Более тугая спираль (0,74 микрона между соседними дорожками, вместо 
1,6 мкм для компакт-дисков). 

3. Красный лазер (с длиной волны 0,65 мкм вместо 0,78 мкм для компакт-дисков). 

Вместе эти усовершенствования позволили увеличить емкость в семь раз, то 
есть с 650 Мбайт до 4,7 Гбайт. Односкоростное устройство чтения БѴБ считы¬ 
вает данные со скоростью 1,4 Мбайт/с (против 150 Кбайт/с для компакт-дисков). 
К сожалению, переход на красный лазер (вроде тех, что используются в супермар¬ 
кетах) означает необходимость установки второго лазера или сложной преобразо¬ 
вательной оптики для возможности считывать на новом устройстве обычных ком¬ 
пакт-дисков. Такую возможность обеспечивают далеко не все устройства чтения 
БѴБ. Кроме того, чтение СБ-К и СБ-К\У на БѴБ-проигрывателе может также 
оказаться невозможным. 

Достаточно ли емкости 4,7 Гбайт? Возможно. При использовании алгоритма 
сжатия МРЕС-2 (Международный стандарт 15 13346) диск емкостью 4,7 Гбайт 
может вместить до 133 мин полноэкранного динамичного видеоизображения вы¬ 
сокого разрешения (720x480), а также звуковую дорожку на восьми языках плюс 
субтитры еще на 32 языках. Около 92 % всех фильмов, сделанных в Голливуде, ко¬ 
роче 133 мин. Тем не менее для некоторых приложений, таких как мультимедиа, 
игры или энциклопедии, может понадобиться носитель большего размера, кроме 
того, возможно, кому-нибудь захочется поместить на диск более одного фильма. 
Поэтому были определены четыре следующих формата: 

1. Односторонний, одноуровневый (4,7 Гбайт). 

2. Односторонний, двухуровневый (8,5 Гбайт). 

3. Двусторонний, одноуровневый (9,4 Гбайт). 

4. Двусторонний, двухуровневый (17 Гбайт). 

Зачем так много форматов? Ответ: политика. Фирмы РЫІірз и 5опу хотели со¬ 
здать односторонний, двухуровневый диск, но фирмам ТозЫЬа и Тіте Шагпег был 
нужен двусторонний, одноуровневый. Фирмы РЬіІірз и 5опу полагали, что клиен¬ 
ты вряд ли будут рады необходимости переворачивать диск, а компания Тіте 
\Ѵагпег не верила, что двусторонние диски будут работать. В результате было при¬ 
нято компромиссное решение: принять стандарты для всех четырех возможных 
комбинаций, а рынок пусть сам разберется, какой из этих стандартов выживет. 

Двухуровневая технология заключается в том, что у диска есть с краю отража¬ 
ющий слой и полуотражающий слой посредине. Считываться будет тот уровень, 
на который будет сфокусирован лазер. Для нижнего уровня требуются питы и про¬ 
межутки большего размера, чтобы надежность считывания не пострадала. В резуль¬ 
тате нижний уровень оказался немного менее емким. 

Двусторонний диск представляет собой просто два обычных 0,6-мм диска, скле¬ 
енных спинками. Чтобы толщина всех типов дисков была одинаковой, односто- 
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рошіий диск состоит из обычного диска толщиной 0,6 мм, приклеенного к пусто¬ 
му поликарбонатиому основанию. (Возможно, в будущем вместо пустышки будут 
приклеивать 133 мин рекламы, в надежде, что покупатели из любопытства загля¬ 
нут туда.) Структура двустороннего двухуровневого диска показана на рис. 5.19. 



Технология ОѴО была разработана консорциумом из 10 компаиий-произво- 
днтслей бытовой электроники, семь из которых были японскими, в тесном сотруд¬ 
ничестве с голливудскими студиями (некоторыми из них владеют японские элек¬ 
тронные компании, входящие в консорциум). Представителей компьютерной и 
телекоммуникационной промышленностей не пригласили на пикник, в результа¬ 
те чего акцент оказался смещен в сторону использования ЭѴЭ для размещения 
на них фильмов в основном в коммерческих целях. Например, стандартные свой¬ 
ства ВѴЭ включают пропуск грязных сцен в режиме реального времени (что по¬ 
зволяет родителям превратить порнофильм в детскую сказку), шестиканальный 
звук и поддержку Рап-апсГЗсап. Последняя особенность позволяет ОѴЭ-проиг- 
рывателю динамически решать, как обрезать левый и правый края фильма (с со¬ 
отношением сторон 3:2), чтобы кадр помещался на экран современного телевизо¬ 
ра (с соотношением сторон 4:3). 

Кроме того, представителям компьютерной промышленности, возможно, про¬ 
сто не пришло бы в голову намеренно добиваться несовместимости дисков, пред¬ 
назначенных для продажи на разных континентах. Эта «функция» была включена 
по требованию Голливуда, поскольку все голливудские фильмы сначала демон¬ 
стрируются на широких экранах США, после чего их везут в Европу. К этому 
времени в США па полках магазинов уже появляются видеоверсии этих фильмов. 
Замысел состоял в том, чтобы гарантировать, что европейские видеомагазины не 
купят диски в США слишком рано, тем самым снизив доходы европейских кино¬ 
театров. Если бы Голливуд занимался компьютерным бизнесом, у нас сейчас были 
бы 3,.5-дюймовые дискеты в США и 9-см диски в Европе. 


Форматирование дисков 

Жесткий диск состоит из стоики сделанных из алюминия, стекла или других ма¬ 
териалов пластин диаметра 5,25 дюйма или 3,5 дюйма (или даже меньших для но¬ 
утбуков), На каждую пластину нанесен тонкий магнитный слой оксида металла. 
После создания па диске нет никакой информации. 
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Прежде чем диском можно будет пользоваться, каждой пластине нужно про¬ 
граммно придать низкоуровневый формат. Этот формат состоит из серий концен¬ 
трических дорожек, содержащих определенное число секторов, с короткими про¬ 
межутками между секторами. Формат сектора показан на рис. 5.20. 


Заголовок 


Данные 


ЕСС 


Рис. 5.20. Сектор диска 


Заголовок начинается с определенной последовательности битов, обеспечиваю¬ 
щей распознавание начала сектора аппаратурой. Он также содержит номера цилин¬ 
дра и сектора и еще некоторую информацию. Размер порции данных определяется 
программой низкоуровневого форматирования. В большинстве дисков используют¬ 
ся 512-байтовые секторы. Поле ЕСС (Еггог Соггесііоп Сосіе — код корректировки 
ошибок, контрольная сумма) содержит избыточную информацию, позволяющую 
обнаруживать (и даже, возможно, исправлять) ошибки чтения. Размер и содержи¬ 
мое этого поля зависят от производителя диска и его желания увеличить емкость 
диска за счет снижения надежности или наоборот, а также способности контролле¬ 
ра поддерживать тот или иной алгоритм подсчета контрольной суммы. Не является 
редкостью, например, 16-байтовое поле ЕСС. Кроме того, все жесткие диски обла¬ 
дают некоторым количеством запасных секторов, используемых для замены сек¬ 
торов с производственными дефектами. 

При низкоуровневом форматировании 0-й сектор располагается на каждой сле¬ 
дующей дорожке со сдвигом относительно предыдущей дорожки. Это смещение, 
называемое перекосом цилиндров, служит увеличению производительности дис¬ 
ка. Замысел состоит в том, чтобы диск мог читать несколько дорожек за одну опера¬ 
цию без потери времени на ожидание. Суть проблемы можно проиллюстрировать 
на рис. 5.14, а. Предположим, необходимо прочитать 18 секторов, начиная с секто¬ 
ра 0 внутренней дорожки. Чтение 16 секторов (полной дорожки) занимает один 
оборот диска, но для перехода на следующую дорожку требуется время. К тому 
моменту, когда считывающая головка будет установлена на нужное место, 17-й сек¬ 
тор (сектор 0 следующей дорожки) уже успеет провернуться под головкой, по¬ 
этому, чтобы его прочитать, придется ждать целый оборот диска. Эта проблема 
решается при помощи разметки секторов со смещением, как показано на рис. 5.21. 

Величина перекоса цилиндров зависит от геометрии диска. Например, для диска, 
вращающегося со скоростью 10 000 об/мин, время одного оборота составляет 6 мс. 
Если на дорожке содержится 300 секторов, сектор проходит под головкой каждые 
20 мкс. За время перемещения головки на соседнюю дорожку, равное 800 мкс, под 
головкой пройдут 40 секторов. Таким образом, перекос цилиндров должен состав¬ 
лять 40 секторов, а не три сектора, как показано на рис. 5.21. Следует также заме¬ 
тить, что переключение с одной головки на другую тоже занимает время, поэтому 
перекос головок присутствует, но он не так велик, как перекос цилиндров. 

В результате низкоуровневого форматирования емкость диска немного умень¬ 
шается в связи с расходами на заголовки сектора, межсекторные промежутки и поля 
ЕСС, а также резервные секторы. Часто полезный объем жесткого диска составляет 
около 80 % от общего объема. Резервные секторы не входят в емкость отформатиро¬ 
ванного диска, поэтому у всех дисков одного типа при поставке абсолютно одина- 
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ковая емкость, независимо от числа дефектных секторов на дисках. (Если число 
дефектных секторов превышает количество запасных секторов, то такой диск не 
проходит контроль качества и не поставляется.) 



В вопросе емкости дисков существует определенная путаница, вызванная же¬ 
ланием производителей создать впечатление, что их диск больше, чем на самом 
деле. Поэтому иногда производителем может рекламироваться неформатированная 
емкость жесткого диска вместо форматированной. Например, возьмем диск с нефор¬ 
матированной емкостью 20х10 9 байт. Он может быть продан за 20-гигабайтный 
диск. Однако после форматирования для данных окажутся доступными только 
2 34 =17,2х10 9 байт. Операционная система обычно считает гигабайты как 2 3(| байт, 
а не ІО 9 байт. В результате она сообщит, что емкость диска составляет 16,0 Гбайт, 
а не 17,2 Гбайт. 

Путаницы добавляют единицы измерения скорости передачи данных, где при¬ 
ставка «гига» снова означает ІО 9 , а не 2 30 . Степени числа 2 используются для изме¬ 
рения объема памяти, дисков, размеров файлов, где кило, мега, гига и тера означа¬ 
ют 2 Ш , 2 20 ,2 30 и 2 40 . Еще запутаннее этот вопрос становится, когда скорость передачи 
данных измеряют то в килобитах в секунду (1000 бит/с), то в килобайтах в секун¬ 
ду (1024 байт/с). 

Форматирование также влияет на производительность диска. Если у диска, 
вращающегося со скоростью 10 000 об/мин, на каждой дорожке по 300 секторов 
размером по 512 байт, то вся дорожка, то есть 153 600 байт, считывается за 6 мс, 
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что составляет скорость считывания данных 25 600 000 байт/с или 24,4 Мбайт/с. 
Быстрее считывать данные невозможно, независимо от используемого интерфейса, 
даже если это 5С5І со скоростью передачи данных 80 Мбайт/с или 160 Мбайт/с. 

Чтение с такой скоростью в течение длительного периода времени требует 
большого буфера в контроллере. Представьте контроллер с буфером размером 
в один сектор, которому дана команда прочитать два сектора подряд. Прочитав 
первый сектор с диска и проверив его контрольную сумму, контроллер должен пе¬ 
редать данные в оперативную память. Пока первый сектор передается в оператив¬ 
ную память, второй сектор уже провернется под головкой, и контроллеру придет¬ 
ся ждать почти полный оборот диска. 

Эта проблема может быть решена, если при форматировании нумеровать секто¬ 
ры не подряд. На рис. 5.22, а показана обычная нумерация секторов. На рис. 5.22,6 
мы видим однократное чередование секторов, предоставляющее контроллеру воз¬ 
можность перевести дух и скопировать прочитанный сектор из буфера в опера¬ 
тивную память. Это позволяет снизить скорость считывания всего в два раза, а не, 
например, в 300 раз, если на одной дорожке помещается 300 секторов. 



а б в 

Рис. 5.22. Без чередования (а); однократное чередование (б); двукратное чередование (в) 

Если процесс копирования очень медленный, может потребоваться двукрат¬ 
ное чередование, показанное на рис. 5.22, в. Если у контроллера буфер только на 
один сектор, то не важно, выполняется ли копирование в оперативную память кон¬ 
троллером, центральным процессором или микросхемой ОМА. На это все равно 
нужно время. Чтобы избежать необходимости в чередовании секторов, контрол¬ 
лер должен иметь достаточно большой буфер, чтобы прочитать в него сразу целую 
дорожку. У многих современных контроллеров такой буфер есть. 

После выполнения низкоуровневого форматирования диск разбивается на 
разделы. Логически каждый раздел диска воспринимается операционной систе¬ 
мой как отдельный диск. На компьютерах с процессором Репііит и большинстве 
других компьютеров в секторе 0 помещается главная загрузочная запись, со¬ 
держащая часть загрузочной программы и таблицу разделов. Таблица разделов 
содержит номера начальных секторов и размеры каждого раздела. На Репііиш- 
компьютерах в таблице разделов есть место для четырех разделов. Если все они 
предназначены для системы ^іпсіоѵѵз, они будут называться устройствами С:, О:, 
Е: и Е:. Если на трех из них размещается система ЛѴіпНохѵз, а на четвертом ІЖІХ, 
тогда ЛѴіпсіо’чѵз будет называть свои разделы С:, О: и Е: (четвертый раздел не будет 
виден системе ШіпсІо\ѵ5). Первое устройство чтения компакт-дисков будет назы- 



Диски 


357 


ваться Е:. Чтобы компьютер мог загружаться с жесткого диска, один из разделов 
должен быть помечен как активный. 

Последним этапом подготовки диска к употреблению заключается в высо¬ 
коуровневом форматировании каждого раздела (по отдельности). Эта операция 
помещает в раздел загрузочный блок, бит-карту или список свободных блоков 
устройства, корневой каталог и пустую файловую систему. Кроме того, в таблицу 
разделов помещается определенный код, указывающий, какая файловая система 
используется в данном разделе, поскольку многие операционные системы тради¬ 
ционно поддерживают несколько несовместимых файловых систем. Затем в одном 
из разделов может быть установлена операционная система. 

При включении питания компьютера запускается базовая система ввода-вы¬ 
вода ВЮ5, которая считывает главную загрузочную запись с диска и передает 
в него управление. Загрузочная программа определяет, который из разделов дис¬ 
ка является активным. Из этого раздела считывается и запускается загрузочный 
сектор. Загрузочный сектор содержит маленькую программу, которая находит 
в корневом каталоге определенный файл (либо операционную систему, либо за¬ 
грузчик больших размеров). Этот файл загружается в память и запускается. 

Алгоритмы планирования перемещения головок 

В этом разделе мы рассмотрим некоторые вопросы, касающиеся в основном дис¬ 
ковых драйверов. Прежде всего определим, сколько времени занимает считыва¬ 
ние или запись одного блока диска. Необходимое для этого время определяется 
тремя факторами: 

1. Время поиска (время перемещения головки на нужный цилиндр). 

2. Задержка вращения (время, требуемое для поворота нужного сектора под 
головку). 

3. Время передачи данных. 

Для большинства дисков первая составляющая (время поиска) существенно 
превосходит остальные две, поэтому значительного увеличения производительно¬ 
сти системы можно добиться, снижая время поиска. 

Если драйвер диска принимает и выполняет запросы по одному в порядке по¬ 
лучения, то есть по принципу «первым пришел — первым обслужен» (РСЕ5, Рігбі 
С оте, Рігзі Зегѵесі), тогда мало что можно сделать для оптимизации времени по¬ 
иска. Однако при сильной загрузке диска возможно применение другой стратегии. 
В этом случае высока вероятность поступления новых запросов от других процес¬ 
сов во время перемещения головки для обработки предыдущего запроса. Многие 
дисковые драйверы содержат таблицу, индексированную по номерам цилиндров, 
в которой в единый связный список собираются все поступившие и ждущие обра¬ 
ботки обращения к цилиндрам. 

С помощью подобной структуры данных можно создать более совершенный 
алгоритм планирования, чем простое обслуживание в порядке поступления за¬ 
просов. Рассмотрим, например, диск с 40 цилиндрами. Поступает запрос на чтение 
блока с цилиндра 11. Во время перемещения головки на 11-й цилиндр поступают 
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новые обращения к цилиндрам 1, 36, 16, 34, 9 и 12. Новые запросы помещаются 
в таблицу, состоящую из отдельных списков для каждого цилиндра. Поступившие 
запросы помечены крестиками на рис. 5.23. 

Начальная Необработанные 



Рис. 5.23. Алгоритм планирования «ближайший цилиндр первым» 


Выполнив первый запрос (обращение к цилиндру 11), драйвер диска должен 
выбрать следующий запрос. Если обслуживать запросы в порядке поступления, 
то он должен переместить головку на цилиндр 1, затем на цилиндр 36 и т. д. В ре¬ 
зультате выполнение этого алгоритма потребует перемещения блока головок на 
10, 35, 20, 18, 25 и 3 цилиндра, что в сумме составит 111 цилиндров. 

Время перемещения головки можно уменьшить, выбирая каждый раз ближай¬ 
ший цилиндр. При той же серии запросов, показанной на рис. 5.23, последователь¬ 
ность их обработки выглядит как ломаная кривая внизу рисунка. При такой по¬ 
следовательности выполнения запросов потребуются перемещения блока головок 
на 1, 3, 7, 15, 33 и 2 цилиндра, что в сумме составит 61 цилиндр. Применение дан¬ 
ного алгоритма, называющегося 55Р (5Ьог1е§1 5еек Рігзі — «ближайший запрос 
первым»), снижает суммарные перемещения головок почти вдвое. 

К сожалению, у данного алгоритма есть свои недостатки. Предположим, во вре¬ 
мя обработки запросов, показанных на рис. 5.23, поступили новые запросы. Напри¬ 
мер, после обработки обращения к цилиндру 16 поступает новый запрос к цилин¬ 
дру 8. Новый запрос будет иметь приоритет над обращением к цилиндру 1. Затем, 
если поступит запрос к цилиндру 13, то головка опять будет перемещаться к ци¬ 
линдру 13 для обработки нового запроса, а запрос к цилиндру 1 останется не¬ 
обработанным. При сильной загрузке диска головка диска будет большую часть 
времени находиться где-то в районе средних цилиндров, а запросам к крайним ци¬ 
линдрам диска придется ждать, пока нагрузка диска случайно не снизится и обра¬ 
щений к середине диска не станет меньше. В результате качество обслуживания 
запросов к цилиндрам, сильно удаленным от середины, может оказаться низким. 
То есть в конфликт вступают принцип минимизации времени отклика и принцип 
справедливости. 

В высотных зданиях также приходится иметь дело с данной проблемой пла¬ 
нирования обслуживания запросов лифта. Вызовы лифта постоянно поступают 
с разных этажей. Компьютер, управляющий лифтом, должен следить за последо¬ 
вательностью поступления запросов и обслуживать их либо в порядке подачи за¬ 
явок, либо обслуживая первым ближайший запрос. 
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Однако в большинстве лифтов применяются различные алгоритмы, пытающи¬ 
еся примирить конфликтующие цели эффективности и справедливости. Обычно 
лифт продолжает двигаться в одном направлении до тех пор, пока на этом направ¬ 
лении более не остается запросов. Затем лифт меняет направление движения. Этот 
алгоритм, называющийся элеваторным алгоритмом, требует от программного 
обеспечения следить всего за одним битом, хранящим информацию о текущем на¬ 
правлении движения, ВВЕРХ или ВНИЗ. Выполнив очередной запрос, диск или 
лифт проверяет значение бита. Если в нем содержится значение ВВЕРХ , кабина 
лифта или блок головок перемещается вверх к следующему запросу. Если в этом 
направлении запросов больше нет, состояние бита инвертируется. 

Рисунок 5.24 иллюстрирует работу элеваторного алгоритма с теми же семью 
запросами, что были использованы в качестве примера на рис. 5.23. Предпола¬ 
гается, что изначально бит направления движения указывал ВВЕРХ. При этом 
цилиндры обслуживаются в порядке 12, 16,34,36,9 и 1, что соответствует переме¬ 
щению блока головок на 1, 4, 18, 2, 27 и 8 цилиндров и в сумме составляет 60 ци¬ 
линдров. В данном случае элеваторный алгоритм оказался даже слегка лучше, чем 
алгоритм 88Р, однако на практике он обычно несколько хуже. Достоинство элева¬ 
торного алгоритма состоит в том, что при любом заданном наборе запросов верхняя 
граница необходимых перемещений блока головок для выполнения всех запросов 
фиксирована и ограничена двойным числом цилиндров. 
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Рис. 5.24. Элеваторный алгоритм планирования обращений к диску 

Незначительная модификация этого алгоритма с меньшим разбросом времени 
отклика состоит в том, чтобы сканировать цилиндры всегда в одном направлении 
[328]. После обслуживания обращения к цилиндру с самым высоким номером блок 
головок перемещается к самому нижнему запрашиваемому цилиндру, после чего 
продолжает движение вверх. Таким образом, самый нижний цилиндр как бы счи¬ 
тается расположенным выше самого верхнего. 

Некоторые контроллеры дисков предоставляют программному обеспечению 
способ узнавать номер текущего сектора под головкой. Такие контроллеры позво¬ 
ляют использовать дополнительный метод оптимизации. Если есть два или более 
запросов к одному и тому же цилиндру, драйвер может выбрать из них тот, сектор 
которого пройдет под головкой первым. Обратите внимание, что при наличии не¬ 
скольких головок у диска последовательные запросы могут обращаться к различ- 
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ным дорожкам на одном цилиндре. Контроллер может практически мгновенно 
переключаться с головки на головку, так как такое переключение не требует ни 
перемещения блока головок, ни ожидания поворота диска. 

Если у диска время перемещения головок значительно ниже задержки, связан¬ 
ной со скоростью вращения диска, тогда следует применять другую стратегию оп¬ 
тимизации. Запросы, ожидающие обработки, должны сортироваться по номерам 
секторов, и как только следующий сектор приблизится к головке, блок головок 
должен быстро переместиться на нужную дорожку, чтобы считать или записать его. 

У современных жестких дисков производительность настолько сильно опреде¬ 
ляется задержками перемещения головок и вращения диска, что читать по одному 
или по два сектора крайне неэффективно. По этой причине многие современные 
контроллеры дисков читают и сохраняют в кэше по нескольку секторов сразу, даже 
если запрашивается всего один сектор. Обычно при этом считывается запрашива¬ 
емый сектор и все остальные секторы этой дорожки, при условии, что для них до¬ 
статочно места в кэше контроллера. Например, у диска, описанного в табл. 5.3, раз¬ 
мер кэша обычно составляет 2 Мбайт или 4 Мбайт. Режим использования кэша 
динамически определяется контроллером. В простейшем режиме кэш разделяет¬ 
ся на две секции, одна для запросов чтения, другая для запросов записи. Если по¬ 
следующий запрос на чтение сектора может быть удовлетворен прямо из кэша 
контроллера, запрашиваемые данные могут быть выданы немедленно. 

Следует отметить, что кэш контроллера диска абсолютно никак не связан с кэ¬ 
шем операционной системы. Кэш контроллера обычно содержит блоки, на кото¬ 
рые запрос еще не поступал, но которые было удобно прочитать, так как они слу¬ 
чайно оказались под головкой при чтении других блоков. Напротив, любой кэш 
операционной системы состоит из блоков, на чтение которых были явно направ¬ 
лены запросы и которые, по мнению операционной системы, могут понадобиться 
снова в ближайшем будущем (например, блок диска, содержащий каталог). 

> При одновременном обслуживании контроллером нескольких устройств таб¬ 
лица запросов, ждущих обработки, должна поддерживаться отдельно для каждого 
устройства. Когда любое из устройств завершает выполнение текущего запроса, 
ему нужно дать команду на перемещение блока головок на цилиндр для выполне¬ 
ния следующего запроса (при условии, что контроллер позволяет работать в режи¬ 
ме перекрывающегося поиска). По завершении текущей операции переноса данных 
может быть выполнена проверка правильного позиционирования блоков головок 
всех устройств. Если хотя бы один блок установлен, может быть начат следующий 
перенос данных. В противном случае драйвер должен выдать новую команду по¬ 
иска цилиндра устройству, только что завершившему операцию переноса данных, 
после чего перейти в состояние ожидания прерывания от диска, установившего 
блок головок на нужный цилиндр и готового к перемещению данных. 

Важно понимать, что во всех вышеизложенных алгоритмах планирования ра¬ 
боты дисков молчаливо подразумевается, что физическая геометрия дисков совпа¬ 
дает с виртуальной. В противном случае планирование обращений к диску не име¬ 
ет никакого смысла, так как операционная система не сможет определить, какой 
цилиндр расположен ближе к цилиндру 39,40-й или 200-й. С другой стороны, если 
контроллер диска способен принимать несколько внешних запросов одновремен¬ 
но, он может выполнять все планирование внутренне. В этом случае алгоритмы 
сохраняют силу, но выполняются на боле низком уровне, в контроллере. 
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Обработка ошибок 

Производители дисков постоянно раздвигают технологические пределы, увеличи¬ 
вая линейную плотность битов. Окружность средней дорожки на 5,25-дюймовом 
жестком диске составляет около 300 мм. Если эта дорожка содержит 300 секторов 
по 512 байт, то, с учетом потерь на межсекторные промежутки, заголовки секто¬ 
ров и поля ЕСС, линейная плотность записи может составлять около 5000 бит/мм. 
Такая высокая плотность записи требует крайне высокой степени гладкости 
поверхности диска и тонкости магнитного покрытия. К сожалению, создать диск с 
такими высокими характеристиками без дефектов невозможно. К тому моменту, 
когда производственные технологии совершенствуются настолько, что позволя¬ 
ют создавать диски с такой плотностью без дефектов, проектировщики дисков уве¬ 
личивают плотность записи для увеличения емкости дисков. Таким образом, дис¬ 
ки, по-видимому, всегда будут содержать определенное количество дефектов. 

Производственные дефекты проявляются в виде дефектных секторов, то есть 
секторов, которые не читаются правильно после записи. Если дефект сектора неве¬ 
лик, например всего несколько бит, такой сектор можно использовать, позволив 
полю ЕСС исправлять ошибки при каждом чтении сектора. При более серьезных 
дефектах ошибка уже не может быть скорректирована. 

Дефектные блоки могут обрабатываться контроллером или операционной сис¬ 
темой. При первом подходе каждый диск проверяется на фабрике, а список дефект¬ 
ных секторов записывается на диск. Вместо каждого дефектного блока использу¬ 
ется запасной. 

Подобная замена может выполняться двумя способами. На рис. 5.25, а показана 
дорожка диска из 30 блоков и 2 запасных. Сектор 7 поврежден. Контроллер может 
пометить один из запасных секторов как сектор 7, как показано на рис. 5.25, б. 
Другой способ состоит в сдвиге всех секторов на один сектор (рис. 5.25, в). В обо¬ 
их случаях контроллер должен знать номера каждого сектора. Он должен хранить 
эту информацию либо в своих внутренних таблицах (по одной на дорожку), либо 
перезаписывая заголовки секторов. При перезаписи заголовков метод на рис. 5.25, в 
требует большей работы (так как для этого нужно перезаписать 23 заголовка), 
но в конечном итоге он дает лучшую производительность, так как при этом вся 
дорожка все так же может быть прочитана за один оборот. 



а б в 

Рис. 5.25. Дорожка диска с дефектным сектором (а); замена дефектного 
сектора запасным (б); сдвиг всех секторов (е) 
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Ошибки могут возникать при выполнении обычных операций после установ¬ 
ки диска. Первая линия обороны при получении ошибки, которую не может ис¬ 
править ЕСС, состоит в простом повторении попытки чтения. Некоторые ошибки 
чтения вызываются попаданием пылинки на головку и исчезают при повторной 
попытке. Если контроллер замечает повторяющиеся ошибки на определенном 
секторе, он может переключиться с него на запасной сектор раньше, чем сектор 
с ошибками выйдет из строя окончательно. При этом данные не будут потеряны, 
а операционная система и пользователь даже не заметят наличия проблемы. Для 
этого обычно применяется метод, показанный на рис. 5.25, б , так как остальные 
секторы этой дорожки могут уже содержать данные. Использование метода, изоб¬ 
раженного на рис. 5.25, в, потребует перезаписи не только всех заголовков, но так¬ 
же и копирования всех данных. 

Как говорилось ранее, есть два основных подхода к исправлению ошибок: об¬ 
работка их контроллером или операционной системой. Если контроллер не может 
прозрачно преобразовывать секторы, тогда этим должна программно заниматься 
операционная система. Это означает, что сначала она должна получить список всех 
дефектных секторов, либо прочитав этот список с диска, либо самостоятельно про¬ 
верив весь диск. Узнав, какие секторы являются дефектными, она может создать 
таблицы соответствий. Если преобразованием занимается операционная система, 
она должна гарантировать, что дефектные секторы не встречаются в файлах, а так¬ 
же в списке или битовом массиве свободных секторов. Один из способов добиться 
этого состоит в создании секретного файла, включающего в себя все дефектные 
секторы. Если этот файл не является частью файловой системы, пользователи не 
смогут его случайно прочитать или, что еще хуже, удалить. 

Однако есть еще одна проблема, связанная с созданием резервных копий диска. 
Если архивация диска выполняется по файлам, то важно, чтобы программа архива¬ 
ции не пыталась копировать файл дефектных блоков. Для этого операционная 
система должна спрятать этот файл настолько хорошо, чтобы даже архивирующая 
программа не смогла его найти. Если же диск архивируется посекторно, а не пофай- 
лово, то будет трудно, если вообще возможно, избежать ошибок чтения во время 
архивации. Единственная надежда на то, что архивирующей программе достанет 
здравого смысла прекратить попытки чтения дефектного сектора после 10 попы¬ 
ток и перейти к чтению следующего сектора. 

Дефектные секторы не являются единственным источником ошибок. Также 
возникают ошибки поиска цилиндра, вызванные механическими проблемами бло¬ 
ка головок. Контроллер следит за положением блока головок. При установке голов¬ 
ки на заданный цилиндр он выдает серию импульсов двигателю блока головок, по 
одному импульсу на цилиндр. Когда блок головок устанавливается в требуемое 
положение, контроллер считывает истинное значение цилиндра из заголовка пер¬ 
вого попавшегося сектора. Если блок головок оказывается не на той дорожке, на 
которой нужно, возникает ошибка поиска. 

Большинство контроллеров жестких дисков автоматически исправляют ошиб¬ 
ки поиска, но большинство контроллеров гибких дисков (включая установленные 
на компьютерах с процессором Репіішп) просто выставляют бит ошибки и ос¬ 
тавляют все остальное драйверу. Драйвер обрабатывает ошибку, издавая команду 
гесаі і Ьгаіе. При этом блок головок отодвигается на самую внешнюю дорожку дис- 
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ка до упора. Это положение принимается контроллером за нулевую дорожку, та¬ 
ким образом, контроллер снова начинает понимать, где находится блок головок. 
Обычно это решает проблему. Если же нет, то либо нужно сменить диск, либо по¬ 
чинить дисковод. 

Как мы видели, контроллер в действительности представляет собой небольшой 
специализированный компьютер, полный программного обеспечения, перемен¬ 
ных, буферов и, по всей видимости, ошибок. Иногда необычное стечение обстоя¬ 
тельств, например приход прерывания с одного устройства, в то время как другое 
устройство выполняет команду гесаІіЬгаІе, может разбудить спящую до тех пор 
ошибку, в результате которой контроллер может войти в бесконечный цикл или 
забыть, что он делал. Разработчики контроллеров обычно готовятся к худшему и 
предоставляют на всякий случай специальный контакт на микросхеме, обращение 
к которому вызывает сброс контроллера. Если никакие другие меры не помогают, 
драйвер может установить этот бит, приводящий к подаче сигнала на такой кон¬ 
такт, и сбросить контроллер. Если и это не помогает, то все, что драйверу остается 
сделать, — это вывести сообщение и сдаться. 

При повторной калибровке дисковод издает скрипучий звук, но в остальном 
эта процедура обычно не очень сильно беспокоит. Однако имеются ситуации, 
в которых повторная калибровка представляет собой серьезную проблему: систе¬ 
мы с ограничениями реального времени. При воспроизведении видео с жесткого 
диска или при перезаписи файлов с винчестера на СО-К крайне важно, чтобы биты 
поступали с жесткого диска с постоянной скоростью. В этих случаях повторная 
калибровка может нарушить непрерывность потока битов и поэтому является не¬ 
приемлемой. Для подобных приложений существуют специальные накопители, 
называющиеся АѴ-дисками (Аибіо Ѵізиаі бізкз — аудио видео диски), которые 
никогда не выполняют операцию повторной калибровки. 

Стабильное запоминающее устройство 

Как мы видели, диски иногда ошибаются. Хорошие секторы могут внезапно стать 
дефектными. Целый диск внезапно может выйти из строя. Чередующиеся наборы 
данных КАШ могут защитить от выхода из строя нескольких секторов или целого 
диска. Однако они не могут защитить от сбоев во время записи, при которых запи¬ 
сываются неверные данные или, что еще хуже, данные записываются не туда, куда 
надо, уничтожая другие важные данные. 

Для некоторых данных крайне важно, чтобы данные никогда не были потеря¬ 
ны или испорчены, даже по причине ошибок диска или центрального процессора. 
В идеале диск должен просто всегда работать без ошибок. К сожалению, это недо¬ 
стижимо. Однако можно создать дисковую подсистему, обладающую следующими 
свойствами: получив команду записи, такое устройство либо корректно записывает 
данные, либо не делает ничего, не изменяя хранящиеся на нем данные. Подобная 
система называется стабильным запоминающим устройством и реализуется про¬ 
граммно [195]. Ниже будет описана разновидность оригинальной идеи. 

Прежде чрм создать алгоритм, важно иметь ясную модель всех возможных оши¬ 
бок. Модель предполагает, что при записи блока (одного или нескольких секто¬ 
ров) эта операция записи либо корректна, либо некорректна, и эта ошибка может 
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быть обнаружена с помощью последующего чтения и изучения полей ЕСС. Гаран¬ 
тированное обнаружение ошибки невозможно в принципе, так как 512-байтовый 
сектор, способный хранить 2 4090 различных комбинаций данных, защищается 16-бай¬ 
товым полем ЕСС, способным принимать всего 2 128 значений 1 , из которых допус¬ 
тимыми являются далеко не все. Таким образом, существуют миллиарды милли¬ 
ардов комбинаций (из которых всего одна верная), соответствующих одному и тому 
же значению поля ЕСС. Вероятность случайного совпадения значения 16-байто¬ 
вого поля ЕСС составляет около 2~ ш , то есть настолько мало, что мы можем назы¬ 
вать это число нулем, хотя в действительности это не так. 

В модели также учитывается, что правильно записанный сектор может внезап¬ 
но стать дефектным и перестать читаться. Однако предполагается, что такие со¬ 
бытия происходят столь редко, что вероятность выхода из строя одинаковых сек¬ 
торов на основном и резервном дисках за небольшой интервал времени (например, 
один день) можно смело считать равной нулю. 

Модель также допускает выход из строя центрального процессора. В этом слу¬ 
чае он просто останавливается. Любая операция записи, совершающаяся в этот 
момент, также останавливается, это приводит к неверным данным в одном секто¬ 
ре и неверному значению поля ЕСС, что может быть обнаружено позднее. При всех 
вышеперечисленных условиях возможно создать 100-процентно надежное стабиль¬ 
ное запоминающее устройство, то есть либо записывающее данные корректно, 
либо оставляющее все хранящиеся данные так, как есть. Конечно, такое устрой¬ 
ство не может противостоять землетрясениям или защитить данные от падения 
компьютера со стометровой высоты. 

Стабильное запоминающее устройство использует пару идентичных дисков, 
в которых соответствующие блоки работают совместно, образуя блоки, защищен¬ 
ные от ошибок. При отсутствии ошибок соответствующие блоки на обоих дисках 
идентичны. Для получения одинакового результата может быть прочитан любой 
из дисков. Для достижения этой цели определены три следующие операции. 

1. Стабильная операция записи. Стабильная операция записи выглядит сле¬ 
дующим образом. Сначала на диск 1 записывается блок данных, который 
затем считывается для проверки корректности выполнения этой опера¬ 
ции. Если обнаруживается ошибка, операции записи и чтения повторяются 
в цикле до тех пор, пока при чтении блока не будет ошибки или пока этот 
цикл не будет выполнен определенное число раз. Если после выполнения 
заданного числа циклов операций записи и чтения успешного результата 
добиться не удается, блок диска помечается как дефектный и вместо него 
используется резервный блок. После этого вся процедура повторяется до тех 
пор, пока блок не будет записан, независимо от того, сколько резервных бло¬ 
ков придется задействовать. Когда наконец удается записать блок на диск 1 
с использованием той же процедуры, записывается и проверяется соот¬ 
ветствующий ему блок диска 2. Если повезет и центральный процессор не 
выйдет из строя до завершения всей операции, блок будет корректно запи¬ 
сан и проверен на обоих дисках. 


У автора здесь дважды упоминается 2 М1 и 2 т , что не может быть верным, так как 16 байт — это 128 бит, 
а не 144. — Примеч, персе. 
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2. Стабильная операция чтения. При этой операции сначала считывается блок 
с диска 1. Если проверка значения поля ЕСС не дает верного результата, 
считывание блока и проверка контрольной суммы повторяются в цикле оп¬ 
ределенное число раз. Если все попытки чтения оказываются неуспешны¬ 
ми, соответствующий блок читается с диска 2. Поскольку операция стабиль¬ 
ной записи создает две проверенные копии блока, а также предполагается, 
что вероятность внезапного выхода из строя сразу двух соответствующих 
блоков за короткий интервал времени пренебрежимо мала, операция стабиль¬ 
ного чтения всегда завершается успешно. 

3. Восстановление от сбоев. После сбоя программа восстановления сканиру¬ 
ет оба диска и сравнивает соответствующие блоки. Если оба блока успешно 
читаются и совпадают, то никаких действий не выполняется. Если у одного 
из блоков при чтении обнаруживается ошибка контрольной суммы (ЕСС), 
то на место дефектного блока записывается правильный блок. Если оба бло¬ 
ка читаются без ошибки, но не совпадают, тогда блок с диска 1 пишется по¬ 
верх блока на диске 2. 

При отсутствии сбоев центрального процессора эта схема всегда работает, так 
как при операции стабильной записи блок всегда записывается дважды, а также 
предполагается, что сразу два соответствующих блока никогда не выходят из строя 
одновременно. Как может повлиять сбой центрального процессора на операцию 
стабильной записи? Результат зависит от того момента, когда произойдет сбой. 
Возможны пять вариантов, показанные на рис. 5.26. 
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Рис. 5.26. Анализ влияния сбоя процессора на стабильность записи 


На рис. 5.26, а сбой центрального процессора происходит прежде, чем запи¬ 
сывается какая-либо копия блока. При восстановлении ничего не меняется и со¬ 
храняется старое значение, что является допустимым. 

На рис. 5.26, б сбой центрального процессора происходит во время записи 
блока на диск 1, в результате чего разрушается содержимое этого блока. Програм¬ 
ма восстановления обнаруживает эту ошибку и восстанавливает блок на диске 1 
с диска 2. Таким образом, результат сбоя устраняется и восстанавливается старое 
значение. 
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На рис. 5.26, в сбой центрального процессора происходит после записи на 
диск 1 , но до записи на диск 2. Программа восстановления копирует блок с дис¬ 
ка 1 на диск 2. Операция записи считается успешной. 

Ситуация на рис. 5.26, г похожа на ситуацию на рис. 5.26, б. При восстановле¬ 
нии дефектный блок заменяется правильным блоком. Окончательным значением 
обоих блоков будет новое значение. 

Наконец, на рис. 5,26, д, как и в ситуации на рис. 5.26, а, программа восстанов¬ 
ления видит, что оба блока успешно читаются и совпадают. Поэтому тут также 
ничего не изменяется. 

К данной схеме применимы различные методы оптимизации и усовершен¬ 
ствования. Прежде всего, сравнение всех блоков, конечно, выполнимо, но все же 
занимает слишком много времени. Значительно ускорить этот процесс можно, 
записывая номера записываемых блоков перед операцией стабильной записи. 
В результате после сбой нужно будет проверить состояние только этих блоков. Это 
может быть реализовано несколькими различными способами. На некоторых 
компьютерах имеется небольшое количество энергонезависимого ОЗУ, пред¬ 
ставляющего собой специальную СМОЗ-память (Сотріешепіагу Меіаі-Охісіе 
ЗетісопсІисГог — комплементарный металло-оксидный полупроводник), питаю¬ 
щуюся от отдельной литиевой батареи. Такие батареи служат помногу лет, воз¬ 
можно, даже в течение всей жизни компьютера. В отличие от оперативной памя¬ 
ти, содержимое которой теряется после сбоя, содержимое энергонезависимого 
ОЗУ сохраняется. В энергонезависимом ОЗУ обычно хранится время и дата (из¬ 
меняющиеся специальной микросхемой). В результате в компьютерах часы идут 
даже тогда, когда питание компьютера выключено. 

Предположим, что несколько байтов энергонезависимого ОЗУ свободны и дос¬ 
тупны операционной системе. Операция стабильной записи может поместить в него 
номер блока, который будет записываться. После успешного завершения операции 
стабильной записи на место номера блока в энергонезависимое ОЗУ записывается 
число, не соответствующее никакому номеру блока, например -1. Таким образом, 
после сбоя программа восстановления может проверить состояние энергонезави¬ 
симого ОЗУ, чтобы определить, не находилась ли во время сбоя операция стабиль¬ 
ной записи в процессе выполнения, и если да, то какой блок записывался. После 
этого остается проверить всего два блока на правильность и совпадение. 

Если энергонезависимое ОЗУ недоступно, его можно имитировать следующим 
образом. В начале выполнения операции стабильной записи в некий фиксирован¬ 
ный блок диска 1 записывается номер записываемого блока. Затем этот блок счи¬ 
тывается для проверки. Когда этот блок успешно записан, записывается и прове¬ 
ряется также соответствующий блок диска 2. Опять же в случае сбоя при записи 
номера блока всегда можно определить, находилась ли в момент сбоя операция 
стабильной записи в состоянии выполнения. Конечно, такой метод имитирования 
энергонезависимого ОЗУ требует дополнительного выполнения восьми дисковых 
операций при стабильной записи каждого блока, поэтому пользоваться таким ме¬ 
тодом нужно лишь в крайнем случае. 

Следует обратить внимание еще на один момент. Мы предположили, что два 
соответствующих блока на разных дисках не смогут стать дефектными за один 
день. Если же пройдет много дней, то такое вполне может произойти. Поэтому раз 
в сутки должно выполняться полное сканирование обоих дисков с исправлением 
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всех ошибок. Таким образом, например, каждое утро оба диска будут гарантиро¬ 
ванно идентичными. Тогда если даже оба блока пары выйдут из строя, но с интер¬ 
валом в несколько дней, все ошибки будут исправлены корректно. 


Таймеры 

Таймеры (также называемые часами) очень важны для работы любой многозадач¬ 
ной системы по ряду причин. Среди многих других задач, они следят за временем 
суток и не позволяют одному процессу надолго занять центральный процессор. 
Программное обеспечение таймера может принимать форму драйвера устройства, 
несмотря на то, что таймер не является ни блочным устройством вроде диска, ни 
символьным устройством типа мыши. Наше изучение таймеров будет проходить 
по тому же сценарию, что и предыдущие разделы: сначала мы рассмотрим аппа¬ 
ратную часть таймеров, а затем познакомимся с программным обеспечением. 


Аппаратная часть таймеров 

В компьютерах широко применяются два типа таймеров. Обе схемы сильно отли¬ 
чаются от наручных и настольных часов. Наиболее простые компьютерные часы 
привязываются по частоте к линии питания переменного напряжения ПО или 
220 В и вызывают прерывания при каждом цикле напряжения с частотой 50 или 
60 Гц. Такие часы очень широко применялись ранее, но сейчас являются редкостью. 

Другой тип часов состоит из трех компонентов: кварцевого генератора, счетчи¬ 
ка и регистра хранения, как показано на рис. 5.27. Если взять кусок кристалла квар¬ 
ца правильного размера и установить его в оправу под давлением, то можно заста¬ 
вить его колебаться и выдавать электрический сигнал с частотой в несколько сот 
мегагерц. Частота зависит от конкретного кристалла, но каждый кристалл выдер¬ 
живает эту частоту с достаточно высокой точностью. С помощью электроники эту 
частоту можно поднять до 1 ГГц или даже до еще более высокой частоты. По край¬ 
ней мере, одна такая схема обязательно присутствует в каждом компьютере, обес¬ 
печивая сигнал синхронизации для различных цепей компьютера. Этот сигнал 
подается на вход декрементного счетчика. Когда содержимое счетчика достигает 
нуля, он вызывает прерывание центрального процессора. 


Кварцевый генератор 



Счетчик уменьшается на единицу 
при каждом импульсе 


Регистр хранения используется 
для загрузки счетчика 


Рис. 5.27. Программируемый таймер 
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У программируемого таймера обычно есть несколько режимов работы. В режи¬ 
ме одновибратора при запуске таймера содержимое регистра хранения копирует¬ 
ся в счетчик. Затем содержимое счетчика уменьшается на единицу при каждом 
импульсе от кристалла. Когда счетчик достигает нуля, он вызывает прерывание и 
останавливается до тех пор, пока он не будет снова явно запущен программным 
обеспечением. В режиме генератора прямоугольных импульсов при достижении 
счетчиком нуля инициируется прерывание, а содержимое регистра хранения авто¬ 
матически копируется в счетчик, и весь процесс повторяется снова бесконечно. 

Преимущество программируемого таймера состоит в том, что частота преры¬ 
ваний от него может управляться программно. Если используется кристалл с ча¬ 
стотой колебаний 500 МГц, то счетчик получает импульс каждые 2 нс. При ис¬ 
пользовании 32-разрядного регистра можно запрограммировать возникновение 
прерываний через равные интервалы времени от 2 нс до 8,6 с, называемые тиками. 
Микросхемы программируемых таймеров обычно содержат два или три незави¬ 
симо программируемых счетчика и помимо этого обладают целым рядом других 
функций (например, могут увеличивать, а не уменьшать значение счетчика, не 
инициировать прерываний и т. д.). 

Чтобы показания таймера не терялись, пока питание компьютера выключено, 
часы большинства компьютеров питаются от аккумулятора. Показания часов счи¬ 
тываются при загрузке операционной системы. Если таких часов у компьютера нет, 
операционная система может запросить дату и время при запуске. Кроме того, си¬ 
стема может узнать эти сведения по сети от удаленного хоста. В любом случае эти 
время и дата транслируются в количество интервалов таймера с какого-либо мо¬ 
мента, например полуночи 1 января 1970 года по всеобщему скоординированно¬ 
му времени (ИТС, Ппіѵегзаі Соогбіпаіесі Тіте), как это делает, например, система 
ІЖІХ. До 1928 года время ИТС называлось средним временем по Гринвичу (СМТ, 
СгеепхѵісЬ Меап Тіте). В системе 'ХѴіпбоѵѵз время отсчитывается от 1 января 
1980 года. При каждом прерывании от таймера счетчик времени увеличивается на 
единицу. В операционной системе обычно присутствуют программы, позволяю¬ 
щие скорректировать показания системных часов. 

Программное обеспечение таймеров 

Все, что делает таймер, аппаратно — он инициирует прерывания через определен¬ 
ные интервалы времени. Все остальное, связанное со временем, должно выполнять¬ 
ся программно драйвером часов. Обязанности драйвера часов варьируются в зави¬ 
симости от операционной системы, но обычными являются следующие функции: 

1. Следят за временем суток. 

2. Не позволяют процессам работать дольше, чем им разрешено. 

3. Ведут учет использования центрального процессора. 

4. Обрабатывают системный вызов а! агт, инициированный процессом пользо¬ 
вателя. 

5. Поддерживают следящие таймеры для операционной системы. 

6. Ведут наблюдение, анализ и сбор статистики. 
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Первая функция часов, поддерживающая время суток (также называемое 
истинным временем), не сложна. Она просто требует увеличения счетчика на еди¬ 
ницу при каждом импульсе сигнала времени часов (рис. 5.28, а). Нужно только 
следить за количеством битов в счетчике времени суток. При частоте импуль¬ 
сов сигнала времени 60 Гц 32-разрядный счетчик переполнится уже за два года. 
Очевидно, система не может хранить значение истинного времени в тиках с 1 ян¬ 
варя 1970 года в 32 бит. 

Для данной проблемы возможны три решения. Во-первых, можно использовать 
64-разрядный счетчик, хотя это потребует больших затрат, так как увеличивать 
значение счетчика придется помногу раз в секунду (рис. 5.28, б). Второй способ со¬ 
стоит в хранении времени суток не в тиках (количестве импульсов сигнала време¬ 
ни), а в секундах, переводя импульсы сигнала времени в секунды при помощи до¬ 
полнительного счетчика (рис. 5.28, б). Поскольку 2 32 с — это больше, чем 136 лет, 
такой метод будет работать вплоть до 22-го века. 

Третий метод состоит в том, чтобы учитывать импульсы сигнала времени, но 
относительно того момента, в который была загружена машина, а не от фиксиро¬ 
ванного внешнего момента. При этом система во время загрузки узнает текущее 
время, которое сохраняет в памяти в любом удобном виде. Позднее, при запросе 
времени, система складывает хранящееся время загрузки со значением счетчика, 
чтобы получить текущее время (рис. 5.28, в). 


-<- 64 бит -»- 


— 32 бит — 


~+ - 32 бит-*-) 

Время суток в импульсах 
сигнала времени 



.л _ 


Счетчик уменьшается 
на единицу при каждом 
импульсе 


/ 

Время суток 
в секундах 


Число импульсов 
сигнала времени 
в текущей секунде 



Время загрузки 
системы в секундах 


Рис. 5.28. Три способа реализации времени суток 


Вторая функция часов состоит в недопущении слишком долгой работы процес¬ 
са. При запуске процесса планировщик инициализирует счетчик, записывая в него 
выделенное этому процессу количество импульсов сигнала времени. При каждом 
прерывании от таймера драйвер таймера уменьшает значение счетчика на 1. Ког¬ 
да значение счетчика достигает нуля, драйвер таймера вызывает планировщик, 
чтобы тот запустил другой процесс. 

Третья функция часов состоит в учете использования центрального процессо¬ 
ра. Наиболее точно это может быть сделано, если при каждом запуске нового про¬ 
цесса запускать второй таймер, независимый от основных системных часов. Когда 
процесс останавливается, значение таймера считывается, чтобы определить, сколь¬ 
ко времени работал процесс. Чтобы все было правильно, значения второго тайме¬ 
ра должны сохраняться на время прерываний. 
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Не столь точный, но более простой метод учета состоит в создании указателя 
текущего процесса в таблице процессов в виде глобальной переменной. При каж¬ 
дом импульсе сигнала времени поле текущего процесса в таблице увеличивается 
на 1. Таким образом, каждый импульс сигнала времени «заботится» о текущем 
процессе. Недостаток этого метода состоит в том, что в случае частых прерываний 
во время работы процесса ему все равно будет засчитана работа в течение полного 
импульса сигнала времени. Точный учет использования времени центрального 
процессора во время прерываний является слишком сложным делом, отнимаю¬ 
щим, в свою очередь, много процессорного времени. 

Во многих системах процесс может попросить операционную систему выдать 
ему сигнал предупреждения после определенного интервала времени. Предупреж¬ 
дение может быть сигналом, прерыванием, сообщением и т. п. Такие предупреж¬ 
дения нужны, например, для работы в сети, при которой пакет, не получивший 
подтверждения в течение определенного интервала времени, должен быть пере¬ 
дан повторно. Другим приложением может быть обучающая программа, ожидаю¬ 
щая ответа на вопрос в течение установленного интервала времени. 

Если драйвер часов управляет достаточным количеством таймеров, он может 
установить таймер для каждого запроса. Если физических таймеров недостаточно, 
они легко могут быть смоделированы программно. Один из способов реализации 
большого числа виртуальных таймеров состоит в создании таблицы, хранящей все 
времена сигналов для обрабатываемых таймеров, а также переменная, в которой 
хранится время срабатывания ближайшего таймера. При каждом обновлении вре¬ 
мени суток драйвер проверяет, не пора ли подавать сигнал от ближайшего тайме¬ 
ра. При этом ищется следующий по времени таймер. 

Если ожидается много сигналов, то более эффективным считается реализовать 
их в виде сортированного связного списка, как показано на рис. 5.29. Каждый эле¬ 
мент списка содержит число импульсов сигнала времени относительно предыду¬ 
щего таймера. В данном примере сигналы должны быть поданы в моменты време¬ 
ни 4203,4207,4213, 4215 и 4216. 


Текущее время Следующий 
сигнал 



Рис. 5.29. Моделирование нескольких виртуальных таймеров 


На рис. 5.29 следующее прерывание произойдет через 3 тика. На каждом тике 
значение переменной А ?ехі зщпаі , хранящей число тиков, оставшееся до подачи 
следующего сигнала, уменьшается на 1. Когда значение этой переменной дости¬ 
гает нуля, подается сигнал в соответствии с первым элементом списка, который 
затем удаляется из списка. После этого переменной Ыехізщпаі присваивается зна¬ 
чение следующего элемента списка, то есть 4 в нашем примере. 
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Обратите внимание, что за время прерывания от таймера драйвер часов должен 
выполнить несколько действий: увеличить показания часов истинного времени, 
уменьшить значение кванта времени, выделенного текущему процессу, и сравнить 
его с нулем, выполнить операцию учета использования центрального процессора 
и уменьшить счетчик таймера тревоги. Однако все эти операции должны быть 
тщательно оптимизированы по времени исполнения, так как они будут повторять¬ 
ся много раз в секунду. 

Операционной системе также требуются таймеры. Они называются сторожевы¬ 
ми таймерами. Например, гибкие диски не вращаются, пока ими не пользуются, что¬ 
бы избежать слишком быстрого изнашивания носителей и головок дисковода. 
Когда требуются данные с гибкого диска, следует запустить двигатель. Только если 
гибкий диск вращается с полной скоростью, может начаться операция ввода-вы¬ 
вода. Когда процесс пытается читать данные с находящегося в состоянии покоя 
гибкого диска, драйвер НГМД запускает двигатель и устанавливает сторожевой 
таймер, чтобы тот инициировал прерывание спустя время, достаточное для разго¬ 
на диска. Сторожевой таймер необходим, так как накопители на гибких дисках не 
умеют формировать прерывания, сообщающие о том, что гибкий диск достаточно 
разогнался. 

Механизм обработки сторожевых таймеров, используемый драйвером часов, 
тот же, что применяется для сигналов пользователя. Единственное отличие состо¬ 
ит в том, что когда таймер срабатывает, вместо подачи сигнала драйвер часов вы¬ 
зывает процедуру, предоставляемую обратившимся к нему процессом. Эта проце¬ 
дура является частью процесса. Она может сделать все, что нужно, даже вызвать 
прерывание, хотя внутри ядра прерывания часто бывают неудобны, а сигналов не 
существует. Вот почему предоставляется механизм сторожевых таймеров. Следу¬ 
ет заметить, что этот механизм работает, только если драйвер таймера и вызывае¬ 
мая им процедура находятся в одном адресном пространстве. 

Последняя функция таймеров в нашем списке — это сбор статистики. В некото¬ 
рых операционных системах предоставляется механизм построения гистограммы, 
показывающей положение счетчика команд программы пользователя. Таким об¬ 
разом, пользователь может видеть, какие процедуры его программы какой процент 
процессорного времени потребляют. Для этого на каждом тике драйвер часов должен 
проверить, собирается ли статистика по текущему процессу, и если да, то определя¬ 
ет, в каком диапазоне адресов находится счетчик команд. После этого значение счет¬ 
чика, соответствующее этому диапазону, увеличивается на единицу. Такой же ме¬ 
тод может применяться для получения статистики по самой операционной системе. 

«Мягкие» таймеры 

У большинства компьютеров есть второй программируемый таймер, который мо¬ 
жет быть установлен для формирования прерываний с той частотой, какая тре¬ 
буется программе. Этот таймер представляет собой добавление к основному сис¬ 
темному таймеру, описанному в предыдущих разделах. До тех пор пока частота 
прерываний невелика, никаких проблем, связанных с использованием второго тай¬ 
мера для прикладных целей, не возникает. Трудности появляются, когда частота 
прерываний прикладного таймера становится очень высокой. Ниже мы кратко 
опишем схему программного таймера, хорошо работающую в различных обсто- 
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ятельствах, даже на высоких частотах. Идея обязана своим появлением Арону 
и Друшелю [15]. Подробности, пожалуйста, смотрите в этой статье. 

Обычно есть два способа управления вводом-выводом: прерывания и опрос. 
Прерывания обладают низким временем задержки, то есть они происходят не¬ 
медленно после самого события или с минимальной задержкой. С другой стороны, 
в современных центральных процессорах прерываниям сопутствуют значительные 
накладные расходы, связанные с необходимостью переключения контекста, а так¬ 
же с их влиянием на конвейер, кэш и буфер быстрого преобразования адреса ТЬВ. 

Вместо прерываний может использоваться опрос приложением какого-либо пор¬ 
та или слова памяти при ожидании события. Этот метод позволяет избежать преры¬ 
ваний, но может привести к значительным задержкам, то есть к замедленной реак¬ 
ции приложения на ожидаемое им событие. Это связано с тем, что событие может 
произойти сразу после опроса, в результате чего задержка реакции составит почти 
целый интервал опроса. В среднем задержка составит половину периода опроса. 

Для некоторых приложений ни накладные расходы прерываний, ни задержка 
опроса неприемлемы. Возьмите, к примеру, такую высокоскоростную сеть, как 
гигабитная сеть ЕсЬегпеС. Эта сеть способна принимать или доставлять пакет пол¬ 
ного размера каждые 12 мкс. Для поддержания оптимальной производительности 
на выходе надо посылать новый пакет каждые 12 мкс. 

Один из способов достижения такой скорости состоит в том, что по заверше¬ 
нии передачи каждого пакета происходит прерывание, либо устанавливается тай¬ 
мер, инициирующий прерывания каждые 12 мкс. Недостаток этого метода — как 
показали измерения, для процессора Репіішп II с частотой 300 МГц одно преры¬ 
вание занимает 4,45 мкс (1335 тактов процессора) [15]. Этот показатель наклад¬ 
ных расходов вряд ли улучшился с 70-х годов. Например, у большинства мини¬ 
компьютеров прерывание занимает всего четыре цикла шины, необходимых для 
помещения в стек счетчика команд и слова состояния процессора, и для загрузки 
новых значений РС и Р5\Ѵ. Сегодняшним процессорам приходится иметь дело с 
конвейером, ММІІ, ТЬВ и кэшем, что увеличивает накладные расходы в несколь¬ 
ко раз. Со временем эти эффекты только ухудшаются, не позволяя использовать 
прерывания от таймера с высокой частотой. 

Идея «мягких» таймеров позволяет избежать лишних прерываний. Вместо 
этого ядро, вызываемое по какой-либо другой причине, перед тем как вернуться 
в режим пользователя, проверяет значение часов реального времени, чтобы про¬ 
верить, не истек ли период ожидания «мягкого» таймера. Если время ожидания 
истекло, выполняется планируемое событие (например, передача пакета или 
проверка, не пришел ли пакет). При этом отпадает необходимость специального 
переключения в режим ядра, так как система и так уже находится в режиме ядра. 
Когда необходимые действия выполнены, «мягкий» таймер снова устанавливает¬ 
ся для ожидания следующего события. Все, что для этого требуется — это взять 
текущее значение часов, прибавить к нему интервал ожидания и сохранить сумму 
в ячейке таймера. 

«Мягкие» таймеры устанавливаются и срабатывают с той скоростью, с кото¬ 
рой выполняются входы в ядро подругам причинам. К этим причинам относятся: 

1. Системные вызовы. 

2. Ошибки преобразования адреса ТЬВ. 
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3. Отсутствие страницы памяти. 

4. Прерывания ввода-вывода. 

5. Временное отсутствие работы для центрального процессора. 

Для определения частоты этих событий Арон и Друшель произвели измерения 
с несколькими вариантами загрузки центрального процессора, включая полнос¬ 
тью загруженный \ѵеЬ-сервер, выполняющий ограниченное скоростью вычисле¬ 
ний фоновое задание, воспроизведение скачиваемого с Интернета аудио в режиме 
реального времени, а также перекомпиляцию ядра системы ІЖІХ. Средний пери¬ 
од обращений к ядру варьировался в диапазоне от 2 до 18 мкс. Примерно поло¬ 
вину этих обращений составляли системные вызовы. Таким образом, в первом 
приближении вызов «мягкого» таймера через каждые 12 мкс является вполне 
выполнимым делом, хотя при этом иногда возможен пропуск временных сроков. 
Однако для таких приложений, как отсылка пакетов, лучше иногда опоздать с от¬ 
правкой пакета на 10 мкс, чем затрачивать на прерывания до 35 % времени цент¬ 
рального процессора. 

Конечно, могут быть периоды, когда нет системных вызовов, ошибок ТЬВ или 
отсутствия страниц памяти. В этом случае «мягкий» таймер не будет обрабаты¬ 
ваться и остановится. Для таких интервалов времени может быть принудительно 
установлена верхняя граница при помощи второго аппаратного таймера, срабаты¬ 
вающего, скажем, раз в 1 мс. Если приложению достаточно всего лишь 1000 паке¬ 
тов в секунду, тогда комбинация «мягких» таймеров и низкочастотного аппа¬ 
ратного таймера может оказаться лучше, чем ввод-вывод, основанный только на 
прерываниях или только на опросе. 


Алфавитно-цифровые терминалы 

У каждого универсального компьютера есть по крайней мере одна клавиатура и один 
дисплей (монитор или плоский экран), используемые для общения с компьюте¬ 
ром. Хотя клавиатура и дисплей персонального компьютера технически являют¬ 
ся отдельными устройствами, они сообща образуют пользовательский интерфейс. 
К мэйнфреймам часто присоединяются специальные устройства, состоящие из 
клавиатуры и дисплея, за которыми могут работать удаленные пользователи. Такие 
устройства исторически называются терминалами. Мы будем продолжать исполь¬ 
зовать этот термин даже при обсуждении персональных компьютеров (по боль¬ 
шей части из-за отсутствия лучшего термина). 

Существует много разновидностей терминалов. На практике сегодня наиболее 
часто встречаются следующие три типа терминалов. 

1. Автономные терминалы с последовательным интерфейсом К5-232 для свя¬ 
зи с мэйнфреймами. 

2. Дисплеи персональных компьютеров с графическим интерфейсом пользо¬ 
вателя. 

3. Сетевые терминалы. 

Каждый из этих типов терминалов занимает свою «экологическую» нишу. 
В следующих разделах мы опишем все эти типы терминалов по очереди. 
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Технические средства терминалов 
с интерфейсом НЗ-232 

Терминалы с интерфейсом К5-232 представляют собой технические устройства, 
состоящие из клавиатуры и дисплея, общающиеся по последовательному интер¬ 
фейсу (рис. 5.30). Эти терминалы соединяются с интерфейсной платой при помо¬ 
щи 9-контактного или 25-контактного разъема. Один из контактов разъема исполь¬ 
зуется для передачи данных, другой контакт — для получения данных, еще один 
контакт представляет собой заземление. Остальные контакты используются для 
различных управляющих функций, большая часть которых не используется. Ли¬ 
нии, по которым символы посылаются побитно (в противоположность передаче 
стразу по 8 бит параллельно, как обычно соединяются с персональными компью¬ 
терами принтеры), называются линиями последовательной передачи. Этот интер¬ 
фейс также используется всеми модемами. В системе ІЖІХ линии последователь¬ 
ной передачи имеют имена вроде /сІеѵ/ЫуІ или /(Іеѵ/Ыу2. В системе \Ѵігк1о\\ъ они 
обычно называются СОМ1 и СОМ2. 


Компьютер 



Рис. 5.30. Терминал с интерфейсом В5-232 общается с компьютером побитно 


Чтобы послать символ по линии последовательной передачи на терминал с ин¬ 
терфейсом К5-232 или модем, компьютер должен передавать данные по одному 
биту, начиная передачу каждого символа со стартового бита и заканчивая одним 
или двумя стоповыми битами для разделения символов. Перед стоповыми битами 
может также добавляться бит четности, обеспечивающий рудиментарное обнару¬ 
жение ошибок, что обычно требуется только при связи с мэйнфреймами. 

Терминалы с интерфейсом К5-232 все еще применяются на мэйнфреймах, иног¬ 
да соединенные по телефонной линии через модем. Их можно встретить в аэро¬ 
портах, банках и других организациях. Даже когда они заменяются персональны¬ 
ми компьютерами, эти персональные компьютеры часто просто эмулируют старые 
терминалы с интерфейсом К.5-232, чтобы не менять программное обеспечение мэйн¬ 
фреймов. 

Такие терминалы также доминировали в мире мини-компьютеров. Большая часть 
программного обеспечения, созданного в тот период, основывалось на этих тер¬ 
миналах. Например, этот тип устройств поддерживается всеми системами ІЖІХ. 

Однако, что еще важнее, многие современные системы ІЖІХ (а также и другие 
операционные системы) предоставляют возможность создать окно, состоящее из 
текстовых строк. Многие программисты работают практически исключительно 
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в текстовом режиме в таких окнах, даже на персональных компьютерах или ра¬ 
бочих станциях. Эти окна обычно эмулируют терминалы с интерфейсом К5-232 
(либо АИЗТстандарт терминала этого типа), поэтому в них может работать огром¬ 
ное количество программ, написанных для подобных терминалов. За долгие годы 
это программное обеспечение, например текстовые редакторы ѵі и етасз, было 
полностью очищено от ошибок и обладает исключительной надежностью, свой¬ 
ством, чрезвычайно ценимым программистами. 

Программное обеспечение, работающее с клавиатурой и дисплеем для этих 
окон, эмулирующих терминал, ничем не отличается от программного обеспечения, 
использующегося для настоящих терминалов. Поскольку эмуляторы этих терми¬ 
налов пользуются такой широкой популярностью, программное обеспечение для 
них сохраняет свое значение, поэтому мы опишем его в следующих двух разделах. 

Терминалы с интерфейсом К5-232 являются алфавитно-цифровыми термина¬ 
лами. Это означает, что экран или окно отображает определенное количество строк 
текста. Обычный размер такого окна составляет 25 строк по 80 символов. Хотя 
иногда такие терминалы (и эмуляторы) поддерживают определенные специаль¬ 
ные символы, в основном они являются исключительно текстовыми. 

Поскольку как компьютеры, так и терминалы работают с целыми символами, 
но вынуждены обмениваться битами по последовательной линии, были разрабо¬ 
таны специальные микросхемы для выполнения преобразований символов в по¬ 
следовательность битов и обратно. Они называются универсальными асинхрон¬ 
ными приемопередатчиками (11АКТ, Ппіѵсгяаі азупсЬгопош гесеіѵегДгапзтіНег). 
Микросхемы И АКТ монтируются на интерфейсных картах, вставляемых в разъем 
шины компьютера, как показано на рис. 5.30. На многих компьютерах один или 
два последовательных порта встроены в материнскую плату. 

Чтобы вывести символ на экран, драйвер терминала записывает этот символ 
в интерфейсную карту, в которой она буферизируется, после чего поразрядно 
выдвигается в последовательную линию универсальным асинхронным приемо¬ 
передатчиком. Например, для аналогового модема, работающего со скоростью 
56 000 бит/с, для передачи одного символа требуется немного более 179 мкс. 
Поскольку такая скорость передачи низка, драйвер обычно передает один символ 
в интерфейсную карту К5-232. После этого драйвер блокируется и ждет прерыва¬ 
ния, которое инициирует интерфейс, передав символ и перейдя в состояние готов¬ 
ности к приему следующего символа. Микросхема И АКТ способна одновременно 
передавать и принимать символы. Прерывание также генерируется при получе¬ 
нии символа, и обычно несколько принятых символов могут сохраняться в буфе¬ 
ре. Получив прерывание, драйвер терминала должен проверить регистр, чтобы 
определить причину прерывания. Некоторые интерфейсные карты имеют соб¬ 
ственный процессор и память и могут одновременно поддерживать несколько 
линий, разгружая тем самым центральный процессор. 

Терминалы с интерфейсом К5-232 могут быть разделены на три категории. 
Наиболее простыми являются печатающие терминалы или телетайпы. Символы, 
набираемые на клавиатуре, посылаются компьютеру. Символы, посланные компь¬ 
ютером, печатаются на бумаге. Такие терминалы уже давно считаются устаревши¬ 
ми и почти не встречаются, разве только в качестве примитивных принтеров. 
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Примитивные электронно-лучевые терминалы работают похоже, но вместо бу¬ 
маги они выводят символы на экран. Их также называют «стеклянными телетай¬ 
пами» (§1аз5 Пуз), поскольку функционально они аналогичны печатающим теле¬ 
тайпам. Термин «Ну» является сокращением слова Теіеіуре®, означающего имя 
компании, бывшей пионером в области компьютерных терминалов. Теперь сокра¬ 
щение «Ну» используется для обозначения любого терминала. Стеклянные теле¬ 
тайпы также устарели. 

Умные электронно-лучевые терминалы на самом деле представляют собой не¬ 
большие специализированные компьютеры. У них есть процессор и память. Они 
также содержат программное обеспечение, хранящееся, как правило, в ПЗУ. С точ¬ 
ки зрения операционной системы основное различие между стеклянным телетай¬ 
пом и умным терминалом состоит в том, что последний понимает управляющие 
последовательности символов, называемые ЕЗС-последовательностями. При помо¬ 
щи передачи такому терминалу символа А5СП Е5С (0x1 В), за которым передается 
еще несколько других символов, можно управлять выводом на экран терминала. 
Например, с помощью Е5С-последовательности можно переместить курсор на 
новую позицию, вывести текст в любое заданное место экрана, очистить экран 
и т. д. Именно такие терминалы используются в системах мэйнфреймов и эмули¬ 
руются другими операционными системами. Ниже мы обсудим программное обес¬ 
печение умных терминалов. 

Программное обеспечение ввода 

Клавиатура и дисплей являются почти независимыми устройствами, поэтому мы 
будем рассматривать их здесь по отдельности. Однако они не совсем независимы, 
так как вводимый с клавиатуры символ обычно выводится на экран. 

Основная работа клавиатурного драйвера состоит в сборе ввода с клавиатуры 
и передаче его программам, читающим с терминала. Существует две философские 
концепции, описывающие работу драйвера. Согласно первой концепции, работа 
драйвера заключается в сборе ввода и передаче его программам безо всяких изме¬ 
нений. Программа, читающая с терминала, получает необработанные последова¬ 
тельности АЗСИ-символов. (Передавать программам пользователя коды клавиш 
неприемлемо, так как они в большой степени зависят от конкретной машины.) 

Эта философия хорошо удовлетворяет потребности таких сложных текстовых 
редакторов, как етасз, который позволяет пользователю связать любое действие 
с любым символом или последовательностью символов. Однако это означает, что 
если пользователь вместо сіаіе наберет на клавиатуре сізіе , а затем исправит ошиб¬ 
ку, удалив три последние символа и допечатав символы аіе, за которыми нажмет 
Епіег, программа пользователя получит 11 следующих АЗСП-спмволов: 

<І5Іе<-<-<-а1:еСК 

Не всем программам нужны эти подробности. Чаще всего им нужна уже исправ¬ 
ленная строка, а не вся последовательность введенных символов. Таким образом, 
формируется вторая философская концепция: драйвер выполняет все редактирова¬ 
ние внутри строки, а программе пользователя передает уже исправленную строку. 
Первая философская концепция является символьно-ориентированной, вторая — 
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строчно-ориентированной. Изначально эти режимы работы драйвера называ¬ 
лись режимом без обработки (или «сырым» режимом) и режимом с обработкой. 
В стандарте РОЗІХ режим с обработкой называется каноническим режимом. 
Неканонический режим соответствует режиму без обработки, хотя многие дета¬ 
ли поведения терминала могут различаться. Совместимые со стандартом Р08ІХ 
системы предоставляют несколько библиотечных функций, поддерживающих 
выбор любого из этих двух режимов, а также изменение многих аспектов конфи¬ 
гурации терминала. 

Основная задача клавиатурного драйвера состоит в сборе символов. Если каж¬ 
дое нажатие на клавишу вызывает прерывание, драйвер может получать введен¬ 
ный символ во время обработки прерывания. Если прерывания преобразуются 
низкоуровневым программным обеспечением в сообщения, каждый полученный 
символ может помещаться в сообщение. В качестве альтернативы символ может 
помещаться в небольшой буфер в памяти, а сообщение использовать только для 
извещения драйвера о том, что что-то прибыло. Второй подход более надежен, 
особенно если сообщение может быть послано только ожидающему его процессу, 
а драйвер клавиатуры может оказаться занятым обработкой предыдущего символа. 

Если терминал находится в каноническом режиме (режиме с обработкой), вве¬ 
денные символы должны храниться в буфере до тех пор, пока не будет введена 
полная строка. Даже если терминал находится в «сыром» режиме, может оказаться, 
что программа еще не запрашивала входные данные, поэтому введенные символы 
все равно должны буферизироваться, чтобы позволить пользователю производить 
упреждающий ввод. (Разработчиков систем, не позволяющих пользователям вво¬ 
дить символы с клавиатуры заранее, следует обмазывать дегтем и вываливать 
в перьях, так как заставлять их пользоваться собственной системой было бы слиш¬ 
ком жестоким наказанием.) 

Для буферизации символов обычно применяются два метода. В первом случае 
в драйвере содержится центральный пул буферов, в каждом из которых хранится 
около 10 символов. С каждым терминалом связана структура данных, содержащая, 
среди прочего, указатель на цепочку буферов, в которых находятся символы, вве¬ 
денные с данного терминала. Чем больше символов введено, тем больше выделя¬ 
ется буферов, соединенных в цепь. Когда символ передается программе пользова¬ 
теля, буферы удаляются и память возвращается центральному пулу. 

Другой подход состоит в том, что буферизация производится прямо в структу¬ 
ре данных терминала, без центрального пула буферов. Поскольку пользователи 
часто печатают команду, обработка которой требует некоторого времени (напри¬ 
мер, перекомпиляция и сборка большой двоичной программы), а затем печатают 
еще несколько строк, буфер драйвера должен вмещать не меньше 200 символов для 
каждого терминала. В крупной системе разделения времени с 100 терминалами 
постоянное выделение 20 Кбайт на буфер ввода с клавиатур кажется чрезмерным, 
поэтому центральный пул буферов размера около 5 Кбайт будет, видимо, доста¬ 
точным. С другой стороны, при выделенном буфере для отдельного терминала 
драйвер становится проще (не требуется управления связанным списком). Такой 
подход является предпочтительным на персональном компьютере с единственной 
клавиатурой. Рисунок 5.31 иллюстрирует разницу между этими двумя методами. 
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Рис. 5.31 . Центральный пул буферов (а); выделенный буфер для каждого терминала (б) 

Хотя клавиатура и дисплей являются логически раздельными устройствами, 
многие пользователи привыкли видеть только что введенные с клавиатуры сим¬ 
волы отображаемыми на экране. Некоторые (старые) терминалы должны были 
автоматически (аппаратно) отображать все, что вводилось с клавиатуры, что не 
только крайне неудобно при вводе паролей, но также значительно ограничивает 
гибкость сложных редакторов и других программ. К счастью, на большинстве тер¬ 
миналов при нажатии клавиши ничего автоматически не отображается. Отобра¬ 
жением символов на экране занимается исключительно программное обеспечение. 
Этот процесс называется печатью эха или эхопечатью. 

Печать эха усложняется тем фактом, что во время нажатия пользователем 
клавиши программа может осуществлять вывод на экран. По меньшей мере, драй¬ 
вер должен решить, где поместить эхо так, чтобы оно не исчезло под выводом 
программы 1 . 

Кроме того, если пользователь ввел более 80 символов в одной строке, вывод 
эха на 80-символьном экране может осуществляться по-разному. В зависимос¬ 
ти от приложения переход на следующую строку может оказаться приемлемым 
либо неприемлемым. Некоторые драйверы просто усекают все введенные строки 
до 80 символов, игнорируя все символы после 80-й колонки. 

Еще одна проблема заключается в обработке табуляторов. Обычно драйвер 
вычисляет текущую позицию курсора, учитывая как вывод программы, так и вы¬ 
вод эха ввода, после чего вычисляет число отображаемых вместо табулятора 
пробелов 2 . 


1 Точнее говоря, это проблема не ввода, то есть драйвера клавиатуры, а вывода. Собственно, и проблемы 
никакой нет. Все символы просто поступают в общий поток стандартного вывода. — Примеч. перев. 

2 Драйвер клавиатуры тут, скорее всего, ни при чем. Преобразованием табулятора в пробелы должна 
заниматься либо программа более высокого уровня, чем драйверы, либо, в крайнем случае, драйвер 
вывода. — Примеч. перев. 
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Наконец, существует проблема эквивалентности устройств. Логически в кон¬ 
це строки текста требуется символ возврата каретки, чтобы переместить курсор 
обратно к колонке 1, и символ перевода строки для перемещения курсора на следу¬ 
ющую строку. Требовать от пользователя вводить оба символа — вряд ли удачная 
мысль, хотя на некоторых терминалах имеется специальная клавиша, посылаю¬ 
щая оба символа с 50-процентной вероятностью сделать это именно в том порядке, 
в котором их ожидает программа. Преобразование всего, что поступает с клавиату¬ 
ры в стандартный внутренний формат, используемый операционной системой, 
является одной из задач драйвера. 

Если стандартом предусматривается хранение только символов перевода стро¬ 
ки (соглашение ІЖІХ), тогда символы возврата каретки должны преобразовывать¬ 
ся в символы перевода строки. Если внутренний формат предусматривает хране¬ 
ние обоих символов (соглашение Шикклѵз), тогда драйвер должен формировать 
символ перевода строки при получении символа возврата каретки и символ возвра¬ 
та каретки при получении символа перевода строки. Независимо от внутренних со¬ 
глашений, терминал может требовать вывода обоих символов для корректного 
управления выводом на экран. Поскольку к большому компьютеру могут оказаться 
подключенными терминалы различных типов, драйвер клавиатуры должен зани¬ 
маться преобразованием всех различных комбинаций символа возврата каретки 
и символа перевода строки во внутренний стандарт, а также следить за правиль¬ 
ностью эхопечати. 

При работе в каноническом режиме некоторые вводимые символы имеют осо¬ 
бое значение. В табл. 5.4. показаны все специальные символы, требуемые стандар¬ 
том Р05ІХ. По умолчанию все они являются управляющими символами, которые 
не должны конфликтовать с вводимым текстом или кодами, используемыми про¬ 
граммами. Однако все символы, кроме последних двух, могут быть программно 
изменены. 


Таблица 5.4. Специальные символы канонического режима 


Символ 

Имя в РОЗІХ 

Комментврий 

СТНЬ+Н 

ЕНА5Е 

Удалить один символ слева 

СТНІ.+1) 

КІИ 

Удалить всю введенную строку 

СТНІ.+Ѵ 

имЕхт 

Интерпретировать следующий символ буквально 

СТНІ.+5 

ЗТОР 

Остановить вывод 

стки-о 

5ТАНТ 

Начать вывод 

РЕЬ 

ІІМТН 

Прервать процесс (ЗІОІЫТ) 

стнь+х 

ошт 

Форсировать дамп памяти (5ІС01ІІТ) 

стнь+о 

ЕОР 

Конец файла 

стны-м 

сн 

Возврат каретки (неизменный) 

стні_+а 

N1. 

Перевод строки (неизменный) 


Символ ЕКА5Е позволяет пользователю удалить один только что введенный 
символ. Обычно для этого применяется клавиша «забой» (Ьаскзрасе) или комби¬ 
нация клавиш СТК1.+Н (обоим вариантам соответствует код 0x08). Этот символ 
не добавляется к очереди символов, а, наоборот, удаляет предыдущий символ из 
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очереди. Печать эха для такого символа должна выглядеть как последовательность 
трех символов: перемещение курсора на одну позицию влево, пробел и еще раз 
возврат на одну позицию, чтобы удалить с экрана предыдущий символ. Если же 
предыдущим символом был табулятор, его удаление зависит от того, как табуля¬ 
тор был отработан при печати. Если он был преобразован в пробелы, то необходи¬ 
ма дополнительная информация о том, насколько далеко следует возвращать кур¬ 
сор. Если же сам табулятор хранится в очереди ввода, он может быть удален, а вся 
строка напечатана еще раз. В большинстве систем символ ЕКА5Е удаляет симво¬ 
лы текущей строки. Символы предыдущей строки и разделяющие строки симво¬ 
лы возврата каретки или перевода строки не удаляются. 

Если пользователь обнаруживал ошибку в начале введенной строки, то един¬ 
ственным способом ее исправления во многих старых системах, не позволяющих 
перемещать курсор по строке, являлось полное удаление всей строки. В этом слу¬ 
чае бывало удобнее воспользоваться специальным символом КІЬЬ, удалявшим всю 
строку сразу. В некоторых системах эта строка полностью исчезала с экрана, но 
в некоторых она оставалась на экране, включая возврат каретки и перевод строки, 
так как многие пользователи любят видеть свою старую строку. Как и символ 
ЕКА5Е, символ КІЬЬ работает только с текущей строкой. При удалении блока сим¬ 
волов драйвер может вернуть освободившиеся буферы в пул. 

Иногда символы ЕКА5Е или КІЬЬ должны быть введены в строку как обычные 
данные. Для этого служит символ ЬЯЕХТ, действующий в качестве префиксного 
символа 1 . В системе ІЖІХ для этого по умолчанию используется сочетание кла¬ 
виш СТКІ.+Ѵ (код 0x16). В более старых системах ІЖІХ в качестве символа КІЬЬ 
часто используется символ @, но впоследствии этот символ стал использоваться 
в адресах электронной почты сети Интернет, как, например, Ііпсіа@с$.ш$Ніпдіоп.есіи. 
Те, кому привычнее старые соглашения, могут переопределить символ КІЬЬ как 
@, но тогда им придется вводить символ @ буквально при вводе адреса электрон¬ 
ной почты. Это можно сделать, нажав на клавиатуре последовательно клавиши 
СТКІ.+Ѵ и @. Сам символ ЬЫЕХТ может быть введен, если дважды нажать клавиши 
СТКІ.+Ѵ. Встретив символ ЬЫЕХТ, драйвер установит флаг, означающий, что следу¬ 
ющий символ не следует подвергать специальной обработке. Сам символ ЬИЕХТ 
не устанавливается в очередь символов. 

Чтобы приостановить и продолжить вывод на экран, также предоставляются 
специальные управляющие коды. В ІЖІХ это символы 5ТОР (СТКІ.+5) и 5ТАКТ 
(СТК1.+0). Эти символы не хранятся в буфере, но используются для установки и 
сброса флага в структуре данных терминала. При каждой операции вывода на эк¬ 
ран проверяется значение этого флага. Если флаг установлен, вывод не произво¬ 
дится. Эхо при этом обычно также подавляется. 

Часто возникает необходимость прервать выполнение отлаживаемой про¬ 
граммы. Для этой цели могут использоваться символы ІЫТК (ОЕІ.) и (ЯЛТ (СПй.+\). 
В системе ІЖІХ клавиша ОЕІ. посылает сигнал прерывания 5ІСЖТ всем процес- 

1 В англоязычной литературе префиксный символ часто называется ЕЗС-символом, так же как и раз¬ 
личные управляющие последовательности ЕЗС-последовательностями. Хотя в качестве префиксно¬ 
го в разных ситуациях могут использоваться различные символы. Строго говоря, ЕЗС-последователь- 
ность — это последовательность символов, начинающаяся с символа Е5С, то есть символа А5СІІ 
0x1 В. — Примеч. перво. 
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сам, запущенным с этого терминала. Реализация может быть непростой. Наибо¬ 
лее сложным является передача информации от драйвера в ту часть системы, ко¬ 
торая занимается обработкой сигналов, поскольку она не ожидает получения 
подобной информации. Результат нажатия клавиш СТКІ.+\ (код ОхІС) аналоги¬ 
чен нажатию клавиши ОЕІ., с той разницей, что процессам посылается сигнал 
5ЮЦШТ, вызывающий прекращение работы процесса с сохранением дампа па¬ 
мяти, если этот сигнал специально не перехватывается процессом. При нажатии 
любой из этих клавиш драйвер должен вывести эхо в виде перевода строки и воз¬ 
врата каретки, а также очистить свой буфер с накопленными введенными симво¬ 
лами, чтобы позволить начать новый ввод. Часто вместо клавиши ОЕI для символа 
ШТК по умолчанию используется сочетание клавиш СТКІ.+С (код 0x03), так как 
с появлением электронно-лучевых дисплеев многие программы стали использо¬ 
вать клавишу ОЕІ. для удаления символа справа от курсора при редактировании. 

Специальный символ ЕОЕ(СТК1_+0), означающий конец файла в системе ІЖІХ, 
сообщает ожидающей ввода программе, что информации на входе больше не будет. 
Программа действует так, как если бы при чтении из файла достигла его конца. 

Некоторые драйверы терминала предоставляют возможность более сложного 
редактирования строки, чем было описано здесь. Они имеют специальные управ¬ 
ляющие символы, позволяющие удалять целиком слова, перемещать курсор впе¬ 
ред и назад по символам и по словам, вставлять текст в середину уже набранной 
строки и т. д. Добавление подобных функций к драйверу значительно увеличи¬ 
вает его. Кроме того, эти функции чаще всего оказываются неиспользуемыми 
экранными редакторами, предпочитающими работать с драйверами клавиатуры 
в «сыром» режиме. 

Программное обеспечение вывода 

Терминальный вывод несколько проще ввода. По большей части компьютер по¬ 
сылает символы терминалу, который их отображает. Обычно блок символов, на¬ 
пример строка, записывается на терминал за один системный вызов. Как правило, 
метод, используемый для терминалов с интерфейсом К.5-232, состоит в том, что 
для каждого терминала выделяется выходной буфер. Эти буферы могут входить 
в тот же пул буферов, что н входные буферы, или представлять собой выделенные 
буферы. Вывод эха на терминал также копируется в буфер. После того как сим¬ 
волы помещены в выходной буфер, первый символ выводится на терминал, пос¬ 
ле чего драйвер блокируется. Когда приходит прерывание, извещающее драйвер 
о готовности терминала принять следующий символ, посылается следующий 
символ и т. д. 

Экранным редакторам и другим сложным программам бывает нужно перери¬ 
совать экран, заменив определенные участки экрана и не меняя остального тек¬ 
ста. Для этого многие терминалы поддерживают наборы управляющих команд, 
позволяющие перемещать курсор, удалять строки и т. д. Эти команды часто реа¬ 
лизуются в виде Е5С-последовательностей, то есть последовательностей симво¬ 
лов, начинающихся с символа ЕЗС (0x1 В). Во времена расцвета терминалов с ин¬ 
терфейсом К.8-232 существовали сотни разновидностей терминалов, у каждого из 
которых был свой набор ЕЗС-последовательностей. В результате было довольно 
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сложно написать программное обеспечение, работающее более чем на одном типе 
терминалов. 

В системе Вегкіеу ІЖІХ было предложено решение этой проблемы, заключаю¬ 
щееся в базе данных терминалов и называющееся іегтсар. Этот программный па¬ 
кет определял множество основных действий, таких как перемещение курсора на 
нужную колонку и строку. Чтобы переместить курсор в определенное место, про¬ 
грамма, например текстовый редактор, формировала свою Е5С-последователь- 
ность, которая преобразовывалась в ЕЗС-последовательность, соответствующую 
тому конкретному терминалу, на который производился вывод. Таким образом, 
текстовый редактор мог работать на любом терминале, включенном в базу данных 
Гегшсар. 

В конце концов производители компьютеров и программного обеспечения 
осознали необходимость стандартизации Е 8 С - п осл едо в ател ь 11 осте й, в результате 
чего был разработан стандарт АЫ8І. Некоторые примеры Е5С-последовательнос- 
тей этого стандарта приведены в табл. 5.5. 

Таблица 5.5. Некоторые Е5С-последовательности стандарта АЫ5І 


Е5С-последовательность Значение 


ЕЗС [пА 

Переместить курсор вверх на п строк 

ЕЗС [пВ 

Переместить курсор вниз на п строк 

ЕЗС [пС 

Переместить курсор вправо на п позиций 

ЕЗС [пО 

Переместить курсор влево на п позиций 

ЕЗС [т;пН 

Переместить курсор в позицию ( т , п) 

ЕЗС ^ 

Очистить экран от курсора (0 до конца, 1 от начала, 2 весь) 

ЕЗС [5К 

Очистить строку от курсора (0 до конца, 1 от начала, 2 всю) 

ЕЗС [пЬ 

Вставить п строк у курсора 

ЕЗС [пМ 

Удалить п строк у курсора 

ЕЗС [пР 

Удалить п символов у курсора 

ЕЗС [п@ 

Вставить п символов у курсора 

ЕЗС [пт 

Разрешить выделение текста (0 — нормальный, 

4 — полужирный, 5 — мерцающий, 7 — инверсный) 

ЕЗС М 

Скроллинг экрана в обратную сторону, если курсор 
находится в верхней строке 


Рассмотрим, как эти Е5С-последовательности могут использоваться тексто¬ 
вым редактором. Предположим, пользователь дает редактору команду удалить 
строку 3, а затем закрыть промежуток между строками 2 и 4. Для этого редактор 
может послать терминалу по последовательной линии следующую Е5С-последо- 
вательность: 

Е5С [3:1Н Е5С [ОК Е5С [1М 

(где пробелы используются только для разделения символов и не передаются 
в линию). Эти последовательности перемещают курсор на начало строки 3, удаля¬ 
ют всю строку, а затем сдвигают строки, начиная с четвертой, вверх на одну по¬ 
зицию. Аналогичные ЕЗС-последовательности могут использоваться для вставки 
в середину текста. Подобным же образом добавляются и удаляются слова. 





Графические интерфейсы пользователя 


383 


Графические интерфейсы пользователя 

На персональных компьютерах могут использоваться символьные интерфейсы. 
В течение нескольких лет доминировала система М5-005 с символьным интер¬ 
фейсом. Однако теперь на большинстве персональных компьютеров использует¬ 
ся графический интерфейс пользователя (СШ, СгарЬісаІ ГІзег Іпіегіасе). Сокра¬ 
щение СІЛ произносится как «гуи» («§ооеу»). 

Графический интерфейс пользователя был придуман Дугласом Энгельбартом 
и его исследовательской группой в Стенфордском исследовательском институте. 
Затем этот интерфейс был скопирован исследователями из Хегох РАИС. Однаж¬ 
ды Стив Джобс, один из основателей компании Арріе, посетив РАИС, увидел гра¬ 
фический интерфейс пользователя на компьютере Хегох. Это натолкнуло его на 
мысль о создании нового компьютера, которым стал компьютер Ілза фирмы Арріе, 
появившийся в 1983 году. Ыза была слишком дорогой машиной и поэтому она не 
получила коммерческого успеха, но ее преемник МасіпіозЬ, разработанный годом 
позже, стал крайне популярен. Компьютер Арріе МасіпІозЬ оказал значительное 
влияние на систему \ѴіпсІо\ѵ5, первая версия которой была представлена кор¬ 
порацией МісгозоЙ в 1985 году, а также на другие системы с графическим интер¬ 
фейсом пользователя. 

Графический интерфейс пользователя состоит из четырех основных элемен¬ 
тов, из первых букв английских названий которых можно сложить слово \ѴІМР 
(\Ѵіпсіо\ѵ5, Ісопз, Мепиз, Роіпііп§ Йеѵісе — окна, пиктограммы, меню, указываю¬ 
щее устройство). Окна представляют собой прямоугольные участки экрана, исполь¬ 
зуемые для запуска программ. Пиктограммами называются небольшие символы, на 
которых можно щелкнуть мышью, чтобы вызвать какое-либо действие. Меню 
являются списками действий, из которых может быть выбрано одно. Наконец, ука¬ 
зывающее устройство — это мышь, шаровой манипулятор или другое устройство, 
используемое для перемещения курсора по экрану и для выбора элементов. 

Программное обеспечение графического интерфейса пользователя может быть 
реализовано либо на уровне пользователя, как это делается в семействе систем 
ІЖІХ, либо включено в саму операционную систему, как в случае \ѴіпсІо\Ѵ5. В сле¬ 
дующих разделах мы познакомимся с аппаратурой и программным обеспечением 
ввода и вывода для графического интерфейса пользователя персональных компью¬ 
теров. В первую очередь будет обсуждаться операционная система ’ѴѴ г іпс1о\ѵ5, од¬ 
нако основные понятия действительны и для других графических интерфейсов 
пользователя. 

Аппаратное обеспечение клавиатуры, мыши 
и дисплея персонального компьютера 

Все современные персональные компьютеры оснащены клавиатурами и растро¬ 
вым графическим дисплеем с изображением, отображаемым в памяти компьюте¬ 
ра. Эти компоненты составляют части самого компьютера. Однако в современном 
персональном компьютере клавиатура и экран являются полностью раздельными 
устройствами, каждое со своим собственным драйвером. 




384 


Глава 5. Ввод-вывод 


Связь с клавиатурой может осуществляться через последовательный порт, 
параллельный порт или порт ІІЗВ. При нажатии любой клавиши центральный 
процессор прерывается, и драйвер клавиатуры извлекает символ, читая порт вво¬ 
да-вывода. Все остальное осуществляется программно, в основном в драйвере кла¬ 
виатуры. 

На Репііит-компьютерах клавиатура содержит встроенный микропроцессор, 
общающийся с микросхемой контроллера, расположенной на материнской плате, 
через специальный последовательный порт. Прерывание возникает при каждом 
нажатии, а также при каждом отпускании клавиши. Аппаратная часть клавиатуры 
поставляет в порт не А5СІІ-код клавиши, а ее номер, или, как его еще называют, 
скан-код. Например, при нажатии клавиши А в регистр ввода-вывода помещается 
код клавиши 30. При этом драйвер должен решить, был ли этот символ строчным, 
прописным или частью какой-либо комбинации клавиш вроде СТЖ+А, АП+А, 
СТК1.+А1.Т+А и т. д. Для этого драйвер должен запоминать все нажатые, но еще не 
отпущенные клавиши (например, 5НІРТ). 

Например, последовательность действий 

Нажать 5НІРТ, нажать А. отпустить А. отпустить 5НІРТ 

означает прописной символ А. Однако последовательность действий 
Нажать 5НІРТ, нажать А. отпустить 5НІРТ. отпустить А 

также означает прописной символ А. Поскольку клавиатурный интерфейс возла¬ 
гает всю тяжесть обработки на программное обеспечение, он является исключи¬ 
тельно гибким. Например, программе пользователя может быть небезразлично, 
введена ли цифра с верхней линейки клавиш или с правой цифровой клавиатуры. 
В принципе драйвер может предоставить такую информацию. 

У большинства персональных компьютеров имеется мышь или, в некоторых 
случаях, шаровой манипулятор, представляющий собой обычную мышь, лежащую 
на спине. Наиболее распространенный тип компьютерных мышей содержит в себе 
резиновый шар, выглядывающий из отверстия в днище мыши и вращающийся, 
когда мышь двигается по столу или коврику. При вращении шар поворачивает 
прижатые к нему резиновые ролики, закрепленные на перпендикулярных осях. 
При движении мыши с запада на восток вращается ось х, а движение мыши с севе¬ 
ра на юг заставляет вращаться ось у. Когда мышь преодолевает по столу опреде¬ 
ленное минимальное расстояние или нажимается или отпускается одна из кнопок 
мыши, мышь посылает компьютеру сообщение. Обычно это минимальное рассто¬ 
яние, которое некоторые люди называют «мики», составляет около 0,1 мм. У мы¬ 
шей может быть одна, две или три кнопки, в зависимости от оценки разработчика 
ми интеллектуальных способностей пользователей — смогут ли они работать более 
чем с одной клавишей. 

Сообщение, посылаемое компьютеру, содержит три параметра: изменения 
позиции по координатам х и у, Дх и Ду и состояние кнопок. Формат сообщения 
зависит от системы и числа кнопок мыши. Обычно оно занимает 3 байт. Боль¬ 
шинство мышей способно передавать до 40 сообщений в секунду, поэтому может 
оказаться, что с момента последнего сообщения мышь переместилась на несколь¬ 
ко мики. 
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Обратите внимание, что мышь сообщает только об изменениях своей позиции, 
а не об абсолютном значении позиции. Если мышь аккуратно поднять и снова по¬ 
ложить, так что шарик не повернется, то сообщений послано не будет. 

Некоторые графические интерфейсы пользователя отличают однократный 
щелчок мыши от двойного щелчка. Если два щелчка мыши достаточно близки 
в пространстве 1 (в миках) и во времени (доли секунды), операционная система сиг¬ 
нализирует о двойном щелчке мыши. Временной интервал, отличающий двойной 
щелчок от двух независимых щелчков, а также скорость перемещения курсора 
мыши по экрану могут быть программно настроены пользователем. 

Рассмотрим теперь аппаратную часть дисплея. Дисплеи могут быть разделе¬ 
ны на две основные категории: устройства с векторной графикой и устройства 
с растровой графикой. Векторные графические устройства могут выполнять та¬ 
кие команды, как вывод точек, рисование линий, геометрических фигур и текста. 
У растровых графических устройств, напротив, область вывода представляет собой 
прямоугольную сетку точек, называемых пикселами, каждая из которых может 
принимать различные значения яркости или цвета. В ранние дни эпохи компью- 
теростроения векторные графические устройства встречались довольно часто, но 
в наши дни единственными векторными графическими устройствами остались 
плоттеры. Все остальные графические устройства используют растровую графику. 

Растровые графические дисплеи реализуются при помощи специального устрой¬ 
ства, называемого графическим адаптером. Графический адаптер содержит специ¬ 
альную память, называемую видео-ОЗУ или видеопамятью и образующую часть 
адресного пространства компьютера. Это означает, что центральный процессор 
обращается к ней так же, как и к остальной оперативной памяти (рис. 5.32). Здесь 
хранится образ экрана либо в символьном, либо в растровом виде. В символьном 
виде каждый байт (или два байта) видеопамяти содержат один отображаемый 
символ. В растровом виде каждый пиксел экрана представляется в видеопамяти 
отдельно. На каждый пиксел отводится от одного бита для простейшего бинарно¬ 
го черно-белого изображения до 24 бит для цветного дисплея высокого качества. 

Центральный Графический 



порт 

Рис. 5.32. Дисплей с общей памятью 

Кроме того, в состав графического адаптера входит микросхема, называющаяся 
видеоконтроллером. Эта микросхема получает символы из видеопамяти и форми- 

1 Пространственный интервал без учета времени не имеет смысла и программно нереализуем. Доста¬ 
точно использования только временного интервала, который, кстати, только и является настраивае¬ 
мым. например, в системе \Ѵіп<1о\ѵ5. — Пргшеч. перев. 
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рует соответствующий им видеосигнал, посылаемый на монитор. Монитор форми¬ 
рует луч электронов, сканирующий экран в горизонтальном направлении. Обыч¬ 
но на экран выводится от 480 до 1024 горизонтальных линий с количеством точек 
на линию от 640 до 1200. Сигнал видеоконтроллера модулирует электронный луч, 
определяя яркость каждого пиксела. У цветных мониторов три луча, для красно¬ 
го, зеленого и синего цветов, модулируемые независимо друг от друга. В плоских 
мониторах также используются пикселы трех цветов, но принципы работы этих 
мониторов выходят за рамки данной книги. 

Видеоконтроллеры могут работать в двух режимах: символьном (используемом 
для простого текста) и растровом (для всего остального). В символьном виде кон¬ 
троллер преобразует каждый символ в прямоугольник пикселов размером 9x14 
(включая промежутки между символами) и составляет из них экран из 25 строк 
по 80 символов. Для этого дисплей должен иметь 350 линий по 720 пикселов в каж¬ 
дой. Чтобы избежать мерцания, каждый кадр должен перерисовываться от 60 до 
100 раз в секунду. 

Для вывода текста на экран видеоконтроллер должен взять из видеопамяти 
первые 80 символов, сформировать для них 14 горизонтальных линий, которые 
подать на монитор, затем взять следующие 80 символов и т. д. Контроллер может 
также брать из видеопамяти по одному символу, что позволяет обойтись без буфе¬ 
ризации символов в контроллере. Растры шрифтов 9x14 бит хранятся в ПЗУ, ис¬ 
пользуемым видеоконтроллером. (ОЗУ может также использоваться для поддерж¬ 
ки настраиваемых шрифтов.) Адресация обращений к ПЗУ 12-разрядная, 8 бит для 
кода символа и 4 бит для линии развертки. Восемь бит в каждом байте ПЗУ уп¬ 
равляют 8 пикселами, 9-й пиксел между символами всегда пустой. Таким образом, 
для вывода строки текста на экран требуется 14 х 80 = 1120 обращений к памяти. 
Такое же число обращений требуется к знакогенератору в ПЗУ. 

На рис. 5.33, а показана часть видеопамяти дисплея, работающего в символь¬ 
ном режиме. Каждый символ на экране (рис. 5.33, б) занимает в видеопамяти два 
байта. Младший байт слова содержит АЗСИ-код отображаемого символа. В стар¬ 
шем байте слова хранятся атрибуты символа, означающие его цвет, мерцание, 
инверсию и т. д. Для экрана из 25 строк по 80 символов требуется 4000 байт видео¬ 
памяти. 



к 


160 


символов 




Экран 



а б 

Рис. 5.33. Видеопамять монохромного дисплея, работающего в символьном виде (а); 
соответствующий экран (б). Символами х обозначены байты атрибутов 
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При работе дисплея в графическом режиме используются те же принципы, 
с той разницей, что каждый пиксел экрана управляется индивидуально и каждо¬ 
му пикселу соответствует своя область (от 1 до 24 бит) в видеопамяти. В простей¬ 
шем случае бинарного изображения каждому пикселу экрана соответствует один 
бит видеопамяти. В случае высококачественного изображения на каждый пиксел 
приходится 24 бит видеопамяти, по 8 бит для интенсивности красного, зеленого 
и синего цветов. Представление цвета в виде разложения на составляющие интен¬ 
сивности красного, зеленого и синего цветов, называющееся по первым буквам их 
английских названий К.СВ (Кеб, Сгееп, Віие), обусловлено свойствами восприя¬ 
тия человеческого глаза. 

Размеры современных растровых графических экранов варьируются в широ¬ 
ких пределах. Самые распространенные стандарты: 640x480 (ѴСА), 800x600 
(5ѴСА), 1024x768 (ХСА), 1280x1024 и 1600x1200 пикселов. Все эти экраны, кро¬ 
ме 1280x1024, имеют соотношение размеров сторон 4:3, что соответствует стан¬ 
дартным телевизионным трубкам (ЫТ5С или РАЕ/5ЕСАМ), и, следовательно, 
позволяет использовать квадратные пикселы. Размер 1280x1024 должен был на са¬ 
мом деле быть 1280x960, но привлекательность числа 1024, видимо, была слиш¬ 
ком велика, чтобы противостоять этому искушению, несмотря на то что пикселы 
при этом слегка искажаются и преобразования в другие размеры усложняются. 
Цветному дисплею, работающему в режиме 1024x768 с 24 бит на пиксел, необхо¬ 
димо 2,25 Мбайт ОЗУ только для хранения изображения. Если весь экран обнов¬ 
ляется 75 раз в секунду, видеопамять должна доставлять данные с постоянной ско¬ 
ростью 169 Мбайт/с. 

Чтобы избежать необходимости управлять такими большими областями памя¬ 
ти, во многих системах имеется возможность использовать меньшее цветовое раз¬ 
решение. В простейшей схеме каждый пиксел представляется 8-разрядным чис¬ 
лом. Оно обычно не содержит самого цвета пиксела, а является индексом в таблице 
цветов, состоящей из 256 24-разрядных элементов формата К.СВ. Эта таблица, на¬ 
зываемая цветовой палитрой и позволяющая экрану содержать в любой момент 
256 произвольных цветов, часто реализуется аппаратно. При изменении, напри¬ 
мер, элемента 7 цветовой палитры, изменятся цвета всех пикселов, содержащих 
байт 7. Использование 8-разрядной цветовой палитры позволяет в три раза сокра¬ 
тить размер, требуемый для хранения изображения, за счет более грубого цвето¬ 
вого разрешения. Цветовая палитра также применяется в схеме сжатия изображе¬ 
ний СІЕ (СгарЬісз Іп1егсЬап§е Еогтаі — формат графического обмена). 

Также применяются цветовые палитры с 16 битами на пиксел. В этом случае 
цветовая палитра содержит 65 536 элементов, что позволяет одновременно исполь¬ 
зовать до 65 536 цветов. Такая схема позволяет достичь гораздо более качествен¬ 
ной цветопередачи, однако размер требуемой видеопамяти при этом методе сокра¬ 
щается всего лишь на одну треть по сравнению с 24-разрядными пикселами. К тому 
же сама цветовая палитра размером 65 536 элементов по 3 байт (192 Кбайт) тоже 
должна где-то храниться. Если она хранится аппаратно (чтобы избежать затрат 
времени на дополнительные обращения к оперативной памяти), хранение такой 
палитры требует существенно больше аппаратных буферов памяти, чем в случае 
8-разрядной цветовой палитры. 
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Возможно и хранение в 16-разрядных пикселах значений цвета в формате КОВ 
с 5 бит на цвет, с одним битом лишним (можно выделить зеленой составляющей 
цвета 6 бит, так как человеческий глаз более чувствителен именно к зеленому цве¬ 
ту.) В результате может получиться система, схожая с 24-разрядным цветом, но с 
меньшим числом градаций яркости для каждого цвета. 

Программное обеспечение ввода 

Получив символ, клавиатурный драйвер должен начать его обработку. Поскольку 
программным обеспечением используются коды символов, а не скан-коды клавиш, 
получаемые драйвером от клавиатуры, драйвер должен преобразовать скан-коды 
в символы с помощью таблицы. Не все ІВМ-совместимые компьютеры использу¬ 
ют стандартные скан-коды клавиш, поэтому, чтобы драйвер мог поддерживать раз¬ 
личные клавиатуры, он должен осуществлять эти преобразования при помощи 
различных таблиц. Проще всего включить нужную таблицу в драйвер во время 
компиляции драйвера. Однако такой подход усложняется тем фактом, что ог¬ 
ромному количеству пользователей требуется набирать тексты на языках, отлич¬ 
ных от английского. В различных странах клавиатуры организуются по-разному, 
и даже в странах, использующих шрифты на основе латиницы, применяются раз¬ 
личные акцентированные буквы, перечеркнутые буквы и т. п., а также знаки пун¬ 
ктуации, отсутствующие в английском языке. 

Для достижения большей гибкости в настройке раскладок клавиатуры 1 многие 
операционные системы предоставляют загружаемые кодовые страницы или, как 
их еще называют, карты клавиш. Они позволяют выбирать способ преобразова¬ 
ния скан-кодов клавиш в символы, предоставляемые приложению, либо во время 
загрузке системы, либо позднее. 

Программное обеспечение вывода для ѴѴіпсІоѵѵз 

Программное обеспечение вывода для графического интерфейса пользователя 
представляет собой весьма обширную тему. Только о графическом интерфейсе 
пользователя системы ’ѴѴ г іпс1о\ѵ5 написано множество книг по полторы тысячи 
страниц (например, [265, 303, 271]). Очевидно, в этом разделе мы сможем лишь 
поверхностно коснуться этой темы и познакомиться с некоторыми основными 
концепциями. Чтобы обсуждение было более конкретным, мы опишем программ¬ 
ный интерфейс приложения ’ѴѴ'тсІоѵѵз АРІ, поддерживаемый всеми 32-разрядны- 
ми версиями системы ’ѴѴ'іпсІоѵѵз. Программное обеспечение вывода для других 
графических интерфейсов пользователя значительно отличается в деталях, но 
в первом приближении имеет много общего с ЛѴіпсІохѵз АРІ. 

Базовым элементом любого графического интерфейса пользователя является 
прямоугольная область экрана, называемая окном. Положение окна и его разме¬ 
ры однозначно определяются координатами (в пикселах) двух противоположных 
углов окна. Окно может содержать заголовок, меню, вертикальную и горизонталь- 


1 А также чтобы избавить пользователя от необходимости транслировать и переустанавливать драй¬ 
вер клавиатуры. — Примеч. перев. 
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ную полосы прокрутки. Типичное окно показано на рис. 5.34. Обратите внимание, 
что система координат, принятая в \Ѵіпс1о\Ѵ5, помещает начало координат в левый 
верхний угол, а координата у увеличивается сверху вниз, что отличается от карте¬ 
зианской системы координат, принятой в математике. 
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Рис. 5.34. Пример окна, расположенного на экране ХСА-дисплея 


При создании окна параметрами указывается, может ли это окно перемещать¬ 
ся пользователем, может ли пользователь изменять его размеры, будут ли у него 
полосы прокрутки и т. п. Главное окно большинства программ обычно можно пе¬ 
ремещать, изменять его размеры и прокручивать его содержимое при помощи по¬ 
лос прокрутки с ползунками. Все эти возможности оказывают огромное влияние 
на способ написания программ. В частности, программы должны получать инфор¬ 
мацию об изменении размеров их окон и должны быть готовы в любое время пере¬ 
рисовать содержимое своих окон, даже когда они совсем этого не ждут. 

Это привело к тому, что программы в системе \Ѵіпс1о\Ѵ5 управляются сообщени¬ 
ями. Действия пользователя, включая работу с клавиатурой или мышью, перехва¬ 
тываются системой \ѴтсІоѵѵ5 и преобразуются в сообщения, адресуемые програм¬ 
ме, владеющей окнами, к которым обращены действия пользователя. У каждой 
программы есть очередь сообщений, в которую направляются все сообщения, отно¬ 
сящиеся к ее окнам. Главный цикл программы состоит из получения следующего 
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сообщения и обработки его с помощью вызова внутренней процедуры, соответ¬ 
ствующей данному типу сообщений. В некоторых случаях система ’ѴѴ'іпсІохѵз мо¬ 
жет вызывать эти процедуры напрямую, минуя очередь сообщений. Эта модель 
принципиально отличается от используемой в системе ІЖІХ модели процедур¬ 
ных программ, для взаимодействия с операционной системой обращающихся к си¬ 
стемным вызовам. 

Поясним программную модель, применяемую в системе ЛѴіпсіохѵз, на примере 
программы, приведенной в листинге 5.2. Здесь мы видим скелет основной програм¬ 
мы для системы \Ѵіпсіо\ѵ5. Она не закончена и не содержит обработки ошибок, но 
для наших целей она включает достаточно подробностей. Программа начинается 
с оператора включения файла заголовка тпсіош.к, содержащего большое количе¬ 
ство макросов, определений типов данных, констант, прототипов функций и дру¬ 
гой информации, необходимой для программ, работающих в системе ’ѴѴ'іпсІоѵѵз. 

Листинг 5.2. Скелет основной программы для системы ѴѴІпсІоѵѵз 

#іпс1ис!е <ьгі псіомз . Н> 

іпі ЫІЫАРІ ЫіпМаіп(НІЫ5Т АЫСЕ И. НІЫ5ТАЫСЕ Иргеѵ. сбаг *32(жІ. іпі іСтсІЗІісм) 

{ 

МСІА55 ѵѵ/псісі Э55: /* объект класса для этого окна */ 

М5С тзд: /* здесь сохраняются входящие сообщения */ 

НМ Нмпб: /* дескриптор (указатель) объекта окна */ 

/* Инициализация обьекта мпсісіазз */ 

мпсІсІазз.ІрРпМпсІРгос = МРгос: /* адрес процедуры обратного вызова */ 
мпсІсІазз.ІрзгСІаззМате = "Ргодгат паше"; /* текст строки заголовка */ 
мпсісіазз.бісоп = ІоасПсоп((ДІІ_І_, ІОІ_АРРІ_ІСАТІ(Ш: /* загрузить пиктограмму программы 

*/ 

місІсІазз.бСигзог = І_оасІСиг50г((Діи_. ЮС_АККОМ): /* загрузить курсор мыши */ 

Кеді БІзегСІ азз(& мпсіс 1 азз): /* сообщить системе ЫІпсЫз об объекте ипсісіазз */ 
бмпсі = СгеабеИіпсІом ( ... ) /* запросить память для окна */ 

5НоиМіпсЫ(ІімісІ, іСтсІЗбоиО: /* отобразить окно на экране */ 

ІІрбабеИіпсІомОшл/псІ); /* сообщение окну с требованием перерисовки */ 
ѵЛтіІе (ОеіМеззадеС&тзд, 0. 0)) { /* получить сообщение из очереди */ 

ТгапзІаіеМеззадеС&тзд): /* транслировать сообщение */ 

ОізраісНМеззадеС&тзд); /* послать сообщение шзд соответствующей процедуре */ 

} 

геіигп(тзд.іѵРагат): 

} 

1 опд САПВАСК МРгосШМ ИмпсІ. ШИТ теззаде. 1)1 ЫТ иіРагагл, 1 опд 1 Рагат) 

{ 

/* Здесь помещаются определения */ 
зилісіт (теззаде) { 

сазе ИМ_СКЕАТЕ: ... : геіигп ... ; /* создать окно */ 
сазе ЫМ_РАІ ЫТ: ... : геіигп ... : /* перерисовать содержимое окна */ 
сазе ИМ_ОЕ$ТКОѴ : ... : геіигп ... : /* уничтожить окно */ 

} 

геіигпШеРкІіпсЫРгос(бь/псІ, теззаде, иіРагат. ІРагат));/* по умолчанию */ 


Основная программа начинается с описания, содержащего ее имя и параметры. 
Макрос У/ІЫАРІ представляет собой указание компилятору использовать опреде¬ 
ленное соглашение о передаче параметров и не будет нас дальше интересовать. 
Первый параметр, к, является дескриптором (описателем) экземпляра, используе- 
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мым для идентификации программы в системе. В определенном смысле интерфейс 
\Ѵіп32 является объектно-ориентированным, это означает, что на этом уровне 
система \Ѵіпс1о\Ѵ5 содержит объекты (например, программы, файлы и окна) с их 
состоянием и связанными с ними программами, называемыми методами, работа¬ 
ющими с этим состоянием. Обращения к объектам производятся при помощи дес¬ 
крипторов, в качестве которых используются указатели на объекты (адреса объек¬ 
тов). В данном случае к однозначно идентифицирует программу. Второй параметр 
более не используется и присутствует только ради обратной совместимости. Тре¬ 
тий параметр, згСтеІ, представляет собой заканчивающийся нулевым байтом текст, 
содержащий командную строку запуска данной программы, даже если программа 
не была запущена из командной строки. Четвертый параметр, іСтсІЗНои), сообща¬ 
ет, должно ли окно программы при запуске занять весь экран, часть экрана или 
окно должно быть минимизировано. 

Это описание процедуры иллюстрирует широко используемое соглашение 
фирмы МісгозоЙ, называемое венгерской нотацией. Название передразнивает так 
называемую польскую нотацию, придуманную польским логиком Й. Лукасевичем 
для представления алгебраических формул без использования скобок. Венгерская 
нотация была изобретена венгерским программистом из корпорации МісгозоЙ 
Чарльзом Шимоньи. Она состоит в использовании первых нескольких символов 
идентификаторов для указания его типа. Среди допустимых символов и типов с 
(сЬагасІег — символ), \ѵ (\ѵопі — слово, сегодня означает 16-разрядное целое без 
знака), і (іпІе§ег — 32-разрядное целое со знаком), 1 (1оп§ — также 32-разрядное 
целое со знаком), з (зСгіп§ — строка), зг (строка, завершающаяся нулевым байтом), 
р (роіпіег — указатель), (п ((ипсііоп — функция) и Ь (Ьапсііе — дескриптор). Так, 
згСтй представляет собой строку, завершающуюся нулем, а іСтсІ5Нот — целое 
число. Многие программисты полагают, что в подобном указании типа переменных 
в их именах мало пользы и оно лишь затрудняет чтение программ для системы 
\Ѵіпсіо\Ѵ5. В системе ІЖІХ подобные соглашения не используются. 

С каждым окном должен быть связан объект класса, описывающий его свойства. 
В листинге 5.2 таким объектом класса является ітсісіпзз. У объекта типа \ѴМІ)СЬА55 
10 полей, четыре из которых инициализируются в листинге 5.2. В реальной про¬ 
грамме остальные шесть также следует проинициализировать. Наиболее важным 
полем является Ір/п\ѴгиІРгос, представляющим собой указатель типа 1оп§ (то есть 
32-разрядный) на функцию, обрабатывающую сообщения, направляемые окну. 
Другие поля, инициализируемые в этом примере, сообщают, какую пиктограмму 
использовать в окне, какой использовать курсор мыши, и задают строку заголовка. 

После инициализации объекта тюпйсіаз 5 вызывается процедура Ке&ізІегСІазз, 
чтобы передать его системе. Так, после этого вызова система \Ѵіік1о\ѵз знает, какую 
процедуру вызывать для обработки различных событий, не устанавливаемых в оче¬ 
редь сообщений. Следующий вызов СгеаіеУ/іпсІоте) запрашивает у системы область 
памяти под структуру данных окна и возвращает дескриптор окна для последую¬ 
щих обращений к нему. Затем программа вызывает еще две системные процеду¬ 
ры, чтобы вывести окно на экран и нарисовать его содержимое. 

Затем программа входит в главный цикл, состоящий из получения сообщения, 
выполнения с ним определенных преобразований и передачи его снова системе 
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на обработку. Для обработки сообщения система вызывает процедуру \ѴпсІРгос. 
В принципе все эти действия можно было организовать проще, но такая архитек¬ 
тура программ сложилась исторически, и теперь мы вынуждены с ней работать. 

Следом за основной программой располагается процедура Ѵ/псІРгос, обраба¬ 
тывающая различные сообщения, посылаемые окну. Ключевое слово САЬЬВАСК 
(обратный вызов) здесь, как и слово 1 ѴШАРІ выше, указывает используемое со¬ 
глашение о передаче параметров процедуры. Первый параметр процедуры — дес¬ 
криптор окна. Второй параметр содержит тип сообщения. В третьем и четвертом 
параметрах передается дополнительная информация. 

Сообщения 1 ѴМ__СКЕАТЕ и \ѴМ_ВЕ5ТРОѴ, извещающие о создании и унич¬ 
тожении окна, посылаются в начале и в конце работы программы. Они предо¬ 
ставляют программе возможность, например, запросить буферы памяти для ра¬ 
боты, а затем вернуть память системе. 

Сообщение третьего типа, 1 ѴМ_РАШТ, является указанием программе запол¬ 
нить окно. Оно может посылаться приложению не только при первой прорисовке 
окна, но также и во время работы программы. В отличие от безоконных текстовых 
систем, программы в системе \Ѵіпс1о\ѵз не могут рассчитывать на то, что все, что 
они когда-либо выведут на экран, будет оставаться там вечно. Поверх одного окна 
может быть выведено или перетащено другое окно, открыты меню, диалоговые 
окна и всплывающие подсказки. При удалении этих элементов окно должно быть 
перерисовано. Чтобы сообщить программе, что окно следует перерисовать, систе¬ 
ма \Ѵіпс1о\ѵ5 посылает ей сообщение \ѴМ_РАІМТ. В нем также предоставляется 
информация о том, какая часть окна должна быть перерисована, что облегчает ра¬ 
боту программе, позволяя перерисовать только часть окна. 

Система \Ѵіпс1о\ѵ5 может заставить программу что-нибудь сделать двумя спо¬ 
собами. Во-первых, система может послать программе сообщение, добавив его к 
очереди сообщений. Этот метод используется для ввода с клавиатуры, мыши и для 
сигналов от таймеров. Другой способ состоит в непосредственном вызове систе¬ 
мой процедуры \ѴгкіРгос. Этот метод используется для всех прочих событий. По¬ 
скольку после полной обработки сообщения система \Ѵіпсіо\ѵз уведомляется об 
этом, она может воздержаться от отправки следующего сообщения до того, как 
будет обработано предыдущее. Таким образом удается избежать возникновения 
ситуации состязаний. 

В системе \ѴіпсІо\ѵ5 используется огромное количество сообщений различных 
типов. Чтобы избежать некорректного поведения программы в случае прихода 
неожиданного сообщения, в конце процедуры \Ѵпс1Ргос следует помещать обраще¬ 
ние к системной процедуре Бе/ШпсіотРгос, таким образом, позволяя обработчи¬ 
ку по умолчанию позаботиться обо всех остальных случаях. 

Подведем итоги вышесказанного. Программа, работающая в системе \Ѵіпс1о\ѵз, 
обычно создает одно или несколько окон, для каждого из которых создается объект 
класса. С каждой программой связаны очередь сообщений и набор процедур обра¬ 
ботки. В конечном итоге поведением программ управляют поступающие события, 
обрабатывающиеся специальными процедурами. Эта модель принципиально 
отличается от подхода, принятого в системе ІЖІХ. 
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Собственно выводом на экран занимается пакет, состоящий из нескольких сот 
процедур, образующих вместе интерфейс графических устройств (СОІ, СгарЬіс 
Оеѵісе Іпіегіасе). Этот пакет может обрабатывать текст и все виды графики. Он 
разрабатывался с расчетом на независимость от платформ и устройств. Прежде чем 
программа может начать вывод в окне, она должна получить контекст устройства, 
представляющий собой внутреннюю структуру данных, содержащую свойства 
окна: текущий шрифт, цвет текста, цвет фона и т. д. Большинство процедур интер¬ 
фейса СОІ используют контекст устройства либо для вывода, либо для получе¬ 
ния или установки свойств. 

Существуют различные способы получения контекста устройства. Простой 
пример его получения и использования выглядит так: 

Исіс = СеЮСЫпсІ) : 

ТехМиКМс, х. у, рзТехі, НепдШ: 

Ке1еазеОС(ІімпсІ, Нсіс); 

Первый оператор получает дескриптор контекста устройства, Мс. Во второй 
строке программы контекст устройства используется для вывода на экран строки 
текста. В параметрах процедуры указываются координаты начала печати ( х , у ), 
указатель на строку и ее длина. Третий вызов освобождает контекст устройства, 
сообщая системе, что программа закончила вывод. Обратите внимание, что кон¬ 
текст устройства к(іс используется аналогично дескриптору файла в ІЖІХ. Кроме 
того, следует заметить, что процедура КеІеазеИС содержит избыточные парамет¬ 
ры. Дескриптор контекста устройства Ыс однозначно указывает окно. Использо¬ 
вание избыточной информации, не требующейся для работы программы, доволь¬ 
но распространено в системе \Ѵіпс1о\ѵ5. 

Также следует заметить, что при получении контекста устройства Нсіс про¬ 
грамма может писать только в клиентскую область окна, но не в заголовок строку 
состояния и т. п. В структуре данных контекста устройства внутренне поддержи¬ 
вается область отсечения. Любой вывод за пределы области отсечения игнориру¬ 
ется. Однако есть другая системная процедура, СеіШпсІошОС, также позволяющая 
получить контекст устройства. Эта процедура устанавливает область отсечения, 
равную всему окну. Другие вызовы ограничивают область отсечения по-другому. 
Наличие в системе нескольких вызовов, выполняющих практически одно и то же, 
является еще одной характеристикой системы \Ѵіпс1о\ѵ5. 

Конечно, невозможно представить в этой книге полное описание работы с ин¬ 
терфейсом графических устройств. Читатели, которых интересует данная тема, 
могут найти дополнительную информацию в ссылках на литературу, приведенных 
выше. Тем не менее следует, возможно, сказать еще несколько слов о важности 
интерфейса СОІ. Интерфейс СОІ содержит различные процедуры, позволяющие 
получать и освобождать контексты устройств, получать информацию о контекстах 
устройств, получать и задавать атрибуты контекстов устройств (например, цвет 
фона), управлять такими объектами интерфейса СОІ, как перья, кисти и шрифты, 
у каждого из которых есть свои атрибуты. Естественно, что интерфейс СОІ содер¬ 
жит большое число процедур для собственно рисования на экране. 

Процедуры графического вывода можно разделить на четыре категории: рисо¬ 
вание прямых и кривых линий, вывод заполненных областей, управление растро- 
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выми изображениями и вывод текста. Пример вывода текста уже был приведен 
нами выше, поэтому давайте познакомимся с другими функциями. Вызов 

ВесСапдІ е(Исіс. хІеГТ, уТор. хпдНР, уЬоПоп): 

рисует на экране заполненный прямоугольник, заданный координатами противо¬ 
положных углов: (хіе/с, уіор) и ( хгіфі , уЪоІіот). Например, 

КесТапд1е(Мс. 2. 1. 6, 4): 

выведет на экран прямоугольник, показанный на рис. 5.35. Толщина линии и цвет 
заливки задаются контекстом устройства. Другие обращения к интерфейсу СОІ 
выглядят аналогично. 



Рис. 5.35. Пример прямоугольника, нарисованного с помощью процедуры Весіапдіе. 

Каждый квадрат соответствует одному пикселу 

Растровые изображения 

Процедуры интерфейса СЭІ являются примерами векторной графики. Они ис¬ 
пользуются для помещения на экран геометрических фигур и текста. Выводимые 
объекты легко могут быть масштабированы для вывода на большие или меньшие 
экраны, при условии что число пикселов на экране одинаково 1 . Вывод объектов 
также в большой степени независим от устройств. Набор обращений к процеду¬ 
рам СОІ может быть собран в файл, описывающий сложные операции рисования. 
Такой файл в системе \Ѵіпс1оѵѵ8 называется метафайлом. Метафайлы широко при¬ 
меняются для передачи изображений от одной программы \Ѵіпсіо\Ѵ5 к другой. Рас¬ 
ширение у таких файлов жт/. 

Многие программы системы \ѴтсІо\ѵ§ позволяют пользователю скопировать 
изображение (или часть его) и поместить в буфер обмена \Ѵіп(іо\Ѵ5. Затем пользо¬ 
ватель может перейти к другой программе и вставить содержимое буфера обмена 
в другой документ. Один из способов реализации данных действий состоит в пред¬ 
ставлении изображения в виде метафайла и помещении его в буфер обмена в фор¬ 
мате жт/. Существуют также и другие методы. 


1 Неясно, чем же тогда отличаются эти экраны. Интерфейс графических устройств \Ѵіп32 СИІ позво¬ 
ляет выводить все объекты не в пикселах, а в виртуальных единицах, что делает масштабирование 
действительно очень простым и эффективным. — Примеч. перво. 
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Не все изображения, с которыми работают компьютеры, могут быть созданы 
при помощи векторной графики. Например, в фотографиях и видеофильмах век¬ 
торная графика не используется. Напротив, изображения в данном случае ска¬ 
нируются, в результате чего получается прямоугольная матрица цветных точек. 
Затем у каждой ячейки квадратной сетки измеряются и преобразуются в число 
значения интенсивности красного, зеленого и синего цвета. Все эти данные сохра¬ 
няются в виде значения одного пиксела. Изображение, состоящее из таких пиксе¬ 
лов, называют растровым. В системе \Ѵіпс1о\ѵз имеется широкий набор средств для 
работы с растровыми изображениями. 

Растровые изображения применяются также для вывода текста. Одни из спо¬ 
собов представления символов каким-либо шрифтом состоит в использовании 
небольших растровых изображений. В этом случае вывод текста на экран превра¬ 
щается в перемещение растровых изображений. 

Для работы с растровыми изображениями часто используется процедура ЫіЫі. 
Она вызывается следующим образом: 

ЬіГЫШзШІс, с)х. сіу, иіс). ИГ, бгсИйс, бх. зу, газГегор): 

В простейшем случае она копирует растровое изображение из одного прямо¬ 
угольника в другой (возможно, в другом окне). Первые три параметра указывают 
окно, в которое будет скопирован прямоугольник, и координаты в этом окне. Сле¬ 
дом указываются ширина и высота прямоугольника, после которых задаются окно, 
из которого копируется прямоугольник, и координаты в нем. Обратите внимание, 
что у каждого окна есть своя система координат с началом (0,0) в верхнем левом 
углу окна. Последний параметр будет описан ниже. Эффект вызова 

ВіГВШМс2. 1. 2. 5. 7. Нсісі. 2. 2. 5КСС0РУ): 

показан на рис. 5,36. Обратите внимание, что скопированной оказалась вся область 
5x7 пикселов символа А, включая цвет фона. 




Рис. 5.36. Копирование растровых изображений с помощью процедуры ВІІВІІ: до (а); после (б) 

Процедура ВИВк может не только копировать растровые изображения. По¬ 
следний параметр процедуры дает возможность выполнять с растровыми изобра¬ 
жениями побитовые логические операции, что позволяет объединять растровые 
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изображения. Например, к ним можно применить логическую операцию ИЛИ или 
сложение по модулю 2. 

Недостатком растровых изображений является сложность их масштабирова¬ 
ния. Символ размера 8х 12 точек выглядит вполне разумно на экране с разрешени¬ 
ем 640x480 пикселов. Однако при копировании этого растрового изображения на 
печатаемый лист с разрешением 1200 точек на дюйм, что соответствует разреше¬ 
нию 10200x13200 точек на листе, ширина символа (8 пикселов) окажется равной 
8/1200 дюйма или около 0,17 мм. Кроме того, копирование с одного устройства на 
другое усложняется различными цветовыми свойствами устройств. 

По этой причине системой \Ѵіпс1о\ѵ§ также поддерживается структура данных, 
называемая аппаратно-независимым растровым изображением (ОІВ, Оеѵісе- 
Іпсіерепсіепі; Вйшар). Изображение такого формата хранится в файлах с расшире¬ 
нием Ътр. В этих файлах помимо пикселов хранятся информационные заголовки 
и цветовая таблица. Такие данные облегчают копирование растровых изображе¬ 
ний между несхожими устройствами. 

Шрифты 

В системе \Ѵіпс1о\ѵ8, предшествовавших версии \Ѵіпс1оѵѵ§ 3.1, символы представлялись 
в виде растровых изображений и копировались на экран или принтер с помощью 
процедуры ВііВІі. Проблема была в том, что, как уже было продемонстрировано, 
растровое изображение, годящееся для экрана, слишком мало для принтера. К тому 
же для каждого символа каждого размера требовался отдельный растр. Другими 
словами, при наличии растрового изображения символа А размером в 10 точек нет 
способа вычислить его для 12-точечного шрифта. Для каждого символа каждого 
шрифта размером от 4 до 120 точек понадобится огромное количество растровых 
изображений. Вся система при этом оказывалась крайне неуклюжей. 

Решение этой проблемы было предложено при помощи шрифтов ТгиеТуре, 
представляющих собой не растровые изображения, а контуры символов. Каждый 
символ определяется последовательностью точек по своему периметру. С помо¬ 
щью такой системы символы легко увеличиваются и уменьшаются. Все, что нуж¬ 
но для этого сделать — это умножить координаты каждой точки на один и тот же 
множитель. Это позволяет масштабировать символы, задавая любой, даже неце¬ 
лый, размер шрифта. После задания нужного размера точки периметра символа 
соединяются друг с другом при помощи нехитрого алгоритма, напоминающего 
картинку-загадку для детей (в последнее время для получения более гладких резуль¬ 
татов используются сплайны). Когда контур полностью обведен, символ может 
быть закрашен. Пример нескольких символов трех различных размеров показан 
на рис. 5.37. 

Таким образом, промасштабировав контур символа и преобразовав его в рас¬ 
тровое изображение, можно гарантировать, что символы, изображаемые на экране 
и печатаемые на принтере, будут близки, насколько это возможно, отличаясь толь¬ 
ко ошибками квантования. Чтобы еще более увеличить качество, можно каждый 
символ снабдить подсказками, помогающими в выполнении растеризации. Напри¬ 
мер, обе засечки у буквы Т должны быть идентичными, что может не получиться 
вследствие ошибок округления. 




Сетевые терминалы 


397 


20 рі: 




Рис. 5.37. Несколько примеров контуров символов различных размеров 


Сетевые терминалы 

Сетевые терминалы используются для того, чтобы соединить удаленного пользова¬ 
теля с компьютером по локальной или глобальной сети. Существует две различные 
философские концепции, касающиеся способа работы сетевых терминалов. Одна 
точка зрения заключается в том, что сетевой терминал должен обладать огромной 
вычислительной мощностью и памятью, что должно позволить работать на нем 
сложным протоколам и снизить объем данных, пересылаемых по сети. (Протоколом 
называется набор запросов и ответов, о которых договариваются отправитель и по¬ 
лучатель, чтобы общаться по сети или другому интерфейсу.) Другая точка зрения 
состоит в том, что терминал должен быть максимально простым и дешевым, в основ¬ 
ном занимающимся лишь отображением пикселов на экране. В следующих двух 
разделах мы на примерах обсудим каждую точку зрения. Сначала мы познакомимся с 
изощренной системой X \Ѵіпсіоѵ/з, затем рассмотрим минимальный терминал 5ЫМ. 

Система X ѴѴіпсІоѵѵ 

Крайняя степень интеллектуального терминала представляет собой терминал, 
содержащий центральный процессор, такой же мощный, как и у основного компью¬ 
тера, с мегабайтами памяти, клавиатурой и мышью. Терминалом такого типа яв¬ 
ляется Х-терминал, на котором работает система X \Ѵіпс1о\ѵ Вузіет (часто назы¬ 
ваемая просто X), разработанная в Массачусетсском технологическом институте 
как часть проекта АсЬепа. Х-терминал представляет собой компьютер, на котором 
работают Х-программы и который взаимодействует с программами, работающи¬ 
ми на удаленном компьютере. 
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Программа, работающая на Х-терминале, собирающая ввод с клавиатуры или 
мыши и принимающая команды от удаленного компьютера, называется Х-серве- 
ром. Она должна следить за тем, которое из окон выбрано в данный момент (то, 
над которым находится курсор мыши). Таким образом Х-сервер узнает, которому 
клиенту направлять ввод с клавиатуры. Х-сервер общается по сети с Х-клиента- 
ми, работающими на удаленном хосте. Он посылает им ввод с клавиатуры и мыши, 
а также принимает от них команды отображения. 

Может показаться странным наличие Х-сервера на терминале и клиентов на 
удаленном хосте, но работа Х-сервера состоит в отображении битов, поэтому он 
должен находиться близко к пользователю. С точки зрения программы, клиент 
велит серверу выполнить те или иные действия, например вывести текст или ото¬ 
бразить геометрическую фигуру. Сервер (в терминале), как и все серверы, просто 
делает то, что ему велят. Схема клиента и сервера показана на рис. 5.38. 


Удаленный хост 


Пространство 
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Пространство 
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Рис. 5.38. Клиенты и серверы в системе ХѴѴіпРоѵѵз 

Система X \Ѵіпбо\ѵз может работать поверх ІЖІХ или другой операционной 
системы. Действительно, на многих разновидностях системы ІЖІХ в качестве 
стандартной оконной системы работает X \Ѵіпс1о\Ѵ8, даже на автономных машинах 
или для доступа к удаленным машинам через Интернет. Что система X \Ѵіпбо\ѵ5 
определяет в действительности — это протокол между Х-клиентом и Х-сервером, 
как показано на рис. 5.38. Не имеет значения, работают ли клиент и сервер на од¬ 
ной машине, соединены ли они локальной сетью на расстоянии сотни метров или 
между ними тысячи километров, и они обмениваются информацией по Интернету. 
Протокол и операционная система идентичны во всех случаях. 

Система X \Ѵіпбо\Ѵ5 представляет собой всего лишь оконную систему. Она не 
является полным графическим интерфейсом пользователя. Для предоставления 
пользователю полного графического интерфейса поверх системы X \Ѵіпс1оѵѵх запус¬ 
каются другие уровни программного обеспечения. Одним таким уровнем являет- 
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ся ХІіЬ, представляющий собой набор библиотечных процедур, необходимых для 
предоставления доступа к функциям системы X \Ѵіпсіо\ѵ5. Эти процедуры обра¬ 
зуют базис системы X \Ѵтсіо\ѵ5, и мы их изучим ниже, но они слишком прими¬ 
тивны для большинства программ пользователя, чтобы их применять напрямую. 
Например, они сообщают о каждом щелчке мыши отдельно, поэтому, чтобы опре¬ 
делить, являются ли два последовательных щелчка двойным щелчком, требуется 
дополнительная обработка этих сообщений на уровне выше ХІіЬ. 

Чтобы облегчить программирование в системе X \Ѵіпс1о\Ѵ8, вместе с ней постав¬ 
ляется набор инструментальных средств, называющийся Іпігіпкіск (встроенные 
средства). Этот уровень управляет кнопками, полосами прокрутки и другими эле¬ 
ментами графического интерфейса пользователя, называемыми («штукови¬ 

на»). Для создания настоящего графического интерфейса пользователя, однородно 
воспринимаемого пользователем, требуется еще один уровень. Наиболее популяр¬ 
ный стандарт графического интерфейса пользователя называется МоііГ. Большин¬ 
ство приложений пользуются именно функциями интерфейса МоСД, а не ХІіЬ. 

Также следует заметить, что управление окнами не является частью самой сис¬ 
темы X \Уіпс1о\ѵ5. Из системы оно вынесено преднамеренно. Вместо нее создани¬ 
ем, удалением и перемещением окон по экрану управляет отдельный Х-клиент- 
ский процесс, называемый оконным менеджером. Для этого он посылает команды 
Х-серверу. Часто он работает на той же машине, что и Х-клиент, но теоретически 
он может работать где угодно. 

Такой модульный дизайн, состоящий из нескольких уровней и большого коли¬ 
чества программ, делает систему X \Ѵіпбо\ѵз в высочайшей степени переносимой 
и гибкой. Она была установлена на большинство версий системы ІЛМІХ, включая 
5ип Боіагіз, В5И, АІХ, Ілпих и т. п„ что предоставило разработчикам стандартный 
интерфейс пользователя на различных платформах. Система X \Ѵіпс1о\ѵз была так¬ 
же установлена на другие операционные системы. Напротив, в системе \Уіпс1о\ѵ5 
управление окнами и графический интерфейс пользователя смешаны вместе в ин¬ 
терфейсе СЭІ и располагаются в ядре, в результате чего управление ими усложня¬ 
ется. Например, графический интерфейс пользователя системы \Ѵіпс1о\ѵз 98 по- 
прежнему в основном остается 16-разрядным, спустя более чем десять лет после 
появления 32-разрядньіх процессоров Іпіеі. 

Взглянем теперь на систему X \Ѵіпс1о\ѵз с точки зрения уровня ХІіЬ. Когда в сис¬ 
теме X \Ѵіпс1о\ѵ5 запускается программа, она устанавливает соединение с одним 
или более Х-серверами — мы будем называть их рабочими станциями, даже если 
они располагаются на той же машине, что и сама программа. Система X \Ѵіпс1о\Ѵ5 
считает это соединение надежным, в том смысле, что потерянные сообщения и дуб¬ 
ликаты сообщений обрабатываются сетевым программным обеспечением и про¬ 
грамме не нужно беспокоиться об ошибках связи. Обычно для соединения клиен¬ 
та и сервера используется пара протоколов ТСР/ІР. 

По соединению передаются следующие четыре типа сообщений: 

1. Команды рисования от программы к рабочей станции. 

2. Ответы рабочей станции на запросы программы. 

3. Объявления о различных событиях, таких как ввод с клавиатуры или мыши 
и т. п. 

4. Сообщения об ошибках. 
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Большинство команд рисования посылаются от программы к рабочей станции 
как сообщения, на которые не ожидается никакого ответа. Причина этого в том, 
что при нахождении клиента и сервера на различных машинах для прохождения 
сообщения и ответа на него по сети может потребоваться значительное время. Бло¬ 
кирование прикладной программы в течение этого периода времени лишь сильно 
замедлило бы ее выполнение без особой на то необходимости. С другой стороны, 
когда программе требуется информация от рабочей станции, она просто должна 
подождать, пока не придет ответ. 

Как и \Уіпс1о\Ѵ5, система X \Ѵіпс1о\ѵз в значительной степени управляется со¬ 
бытиями. Поток событий направляется от рабочей станции к программе, обычно 
в ответ на некое действие пользователя, например ввод с клавиатуры, перемещение 
мыши или открытие окна. Каждое сообщение имеет 32 байт в длину, из которых 
первый байт содержит тип сообщения, а остальные 31 байт содержат дополнитель¬ 
ную информацию. Существует несколько десятков сообщений, но программе по¬ 
сылаются только те сообщения, о которых она заявила, что хочет сама их обраба¬ 
тывать. Например, если программу не интересуют такие события, как отпускание 
клавиш, то о таких событиях ей не сообщается. Как и в \Уіпс1о\Ѵ5, события уста¬ 
навливаются в очередь, из которой их читает программа. Однако в отличие от 
\Ѵіпс1о\Ѵ5 операционная система никогда не вызывает процедуры прикладной про¬ 
граммы сама. Операционная система даже не знает, какая процедура, какие собы¬ 
тия обрабатывает. 

Ключевой концепцией системы X \ѴіпсІо\ѵз является ресурс. Ресурсом назы¬ 
вается структура данных, хранящая определенную информацию. Прикладные про¬ 
граммы создают ресурсы на рабочих станциях. Ресурсы могут использоваться со¬ 
вместно несколькими процессами на рабочей станции. Обычно ресурсы живут 
недолго и не переживают перезагрузки рабочей станции. К типичным ресурсам 
относятся окна, шрифты, карты цветов (цветовые палитры) карты пикселов (рас¬ 
тровые изображения), курсоры и графические контексты. Последние использу¬ 
ются для связи свойств с окнами и концептуально схожи с контекстами устройств 

В \УІПСІО\Ѵ5. 

Грубый незаконченный скелет программы для системы X ^іпс1о\ѵ5 приведен 
в листинге 5.3. В начале этой программы включаются необходимые файлы заго¬ 
ловков, после чего объявляются переменные. Затем она устанавливает соедине¬ 
ние с Х-сервером, указанным как параметр процедуры XОрепОщЛау. После этого 
программа запрашивает память для ресурса окна и сохраняет дескриптор окна 
в переменной тп. В действительности здесь должна производиться определенная 
инициализация. Затем программа сообщает оконному менеджеру о существова¬ 
нии нового окна. 


Листинг 5.3. Скелет прикладной программы для системы X ѴѴіпЗоѵѵз 


Ііпсіийе <Х11/ХНЬ.Н> 

Ііпсіисіе <Х11/ХиЫ 1.И> 
паіп(іп1; агдс. сИаг * агдѵ[]) 

/* идентификатор сервера */ 

/* идентификатор окна */ 

/* идентификатор графического контекста */ 
/* место хранения для одного события */ 


йі зрі ау сіі 5р: 
Ніпсіоіл/ іл/іп; 

6С дс: 

ХЕѵепІ; еѵеігЬ; 




Сетевые терминалы 


401 


ІПІ гиппіпд = 1; 

сіізр = ХОрепОі зрі ау( "сіі зрі ау_пате"): /* 

ѵлп = ХСгеаІеЗітрІеИіпсІоЩсІізр, ... ); /* 
ХЗеІЗІапсІагсІРгорегІіезСсІізр. ...): /* 

дс = ХСгеа1зеСС(с1ізр. ѵлп, 0, 0); /* 

ХЗеІесІІприКсіізр. міп. ВиШопРгеззМазк | 
ХМарКаізесКсІізр. иіп); /* 

иМІе (гилпілд) { 

ХМехРЕѵелКРізр, &еѵепІ); /* 

зѵлТсіі (еѵепі.іуре) { 

сазе Ехрозе: ...; Ьгеак; /* 

сазе ВиШюРгезз: ...: Ьгеак; /* 

сазе Кеургезз: ...; Ьгеак; /* 

} 

} 

ХЕгееССЩізр. дс); /* 

ХОезТгоуМіпсІоиСсІізр. міп): /* 

ХСІозеОізрІау(сІізр); /* 


установить соединение с Х-сервером */ 
запросить память для нового окна */ 
объявить об окне оконному менеджеру */ 
создать графический контекст */ 
КеуРгеззМазк | ЕхрозигеИазк); 
отобразить окно: послать событие Ехрозе */ 

получить следующее событие */ 

перерисовать окно */ 
обработать щелчок мыши */ 
обработать ввод с клавиатуры */ 


освободить графический контекст */ 
вернуть память, занимаемую окном */ 
разорвать сетевое соединение */ 


Вызов ХСгеаІеСС создает графический контекст, в котором сохраняются свой¬ 
ства окна. В более полной программе они, возможно, в этом месте будут проинициа- 
лизированы. Следующая строка, обращаясь к системной процедуре ХЗеІесІІприІ, 
сообщает Х-серверу, какие события программа собирается обрабатывать сама. 
В данном случае ее интересуют щелчки мыши, нажатия на клавиши и открытие 
окон. В действительности программы обычно обрабатывают также и другие собы¬ 
тия. Наконец, вызов ХМарКаЫей отображает новое окно на экран поверх осталь¬ 
ных окон. С этого момента окно становится видимым на экране. 

Главный цикл состоит из двух операторов и логически значительно проще, чем 
соответствующий цикл в системе \Уіпс1о\ѵ5. Первый оператор здесь получает со¬ 
бытие, а второй осуществляет диспетчеризацию событий, направляя их на обра¬ 
ботку в соответствии с типами. Когда событие сообщает программе, что ее вы¬ 
полнение завершается, значение логической переменной гиппіпд устанавливается 
равным 0 и выполнение цикла прекращается. Перед тем как закончить свою рабо¬ 
ту, программа освобождает графический контекст, окно и соединение. 

Следует отметить, что далеко не всем программистам нравится графический 
интерфейс пользователя. Многие предпочитают традиционный интерфейс команд¬ 
ной строки, вроде обсуждавшегося в разделе «Программное обеспечение ввода» 
данной главы. Системой X \Уіпс1о\ѵз интерфейс командной строки поддерживает¬ 
ся при помощи программы хіегт. Эта программа эмулирует старый «умный» тер¬ 
минал ѴТ102, поддерживающий полный набор Е5С-последовательностей. В этих 
окнах без каких бы то ни было переделок работают текстовые редакторы ѵі и етасз, 
а также другое программное обеспечение, использующее базу данных Сеппсар, 


Сетевой терминал 5УМ 

В течение многих лет основная компьютерная парадигма колебалась между центра¬ 
лизованными и децентрализованными вычислениями. Первые компьютеры, такие 
как ЕШАС, были на самом деле персональными компьютерами, хотя и очень 
большими, поскольку только один пользователь мог работать на таком компьюте- 
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ре в каждый момент времени. Затем появились системы разделения времени, в ко¬ 
торых много удаленных пользователей одновременно работали на большом цен¬ 
тральном компьютере. Потом наступила эра персональных компьютеров, то есть 
у пользователей снова появились собственные компьютеры. 

Хотя децентрализованная модель персональных компьютеров обладает опреде¬ 
ленными преимуществами, у нее есть также серьезные недостатки, которые только 
последнее время начинают серьезно рассматриваться. Возможно, самая большая 
проблема персональных компьютеров состоит в том, что у каждого ПК имеется 
большой жесткий диск и сложное программное обеспечение, которым требуется 
управлять. Например, при выходе новой версии операционной системы на каждой 
машине отдельно потребуется выполнить обновление программного обеспечения, 
что может занять довольно много времени. В большинстве корпораций затраты на 
выполнение подобного рода работ сопоставимы со стоимостью оборудования 
и самого программного обеспечения. Домашним пользователям компьютеров не 
нужно платить самим себе за эту работу, однако далеко не все пользователи могут 
выполнить ее корректно, и еще меньшему числу пользователей нравится этим за¬ 
ниматься. В централизованных системах программное обеспечение должно быть 
обновлено лишь на одной машине или небольшом количестве машин, для обслу¬ 
живания которых у корпорации обычно имеется штат экспертов, способных вы¬ 
полнить эту работу. 

Помимо периодического обновления программного обеспечения, пользовате¬ 
лям также следует регулярно архивировать свои гигабайтные файловые системы, 
хотя мало кто этим занимается. Когда случается несчастье, пользователям остает¬ 
ся только причитать. В централизованной системе резервные копии могут каждую 
ночь записываться автоматами на магнитные ленты. 

Еще одно преимущество централизованной системы состоит в том, что в этом 
случае упрощается совместное использование ресурсов. В системе из 64 удален¬ 
ных пользователей, у каждого из которых есть по 64 Мбайт оперативной памяти, 
большую часть времени значительная часть памяти будет оставаться неиспользу¬ 
емой. В централизованной системе с 4 Гбайт ОЗУ никогда не случается так, что 
какому-либо пользователю временно требуется много оперативной памяти, но он 
не может ее получить, так как она кем-то занята. Тот же аргумент справедлив для 
дискового пространства и других ресурсов. 

Вероятно, мы не сильно ошибемся, если скажем, что большинству пользовате¬ 
лей нужна высокопроизводительная интерактивная компьютерная среда, но они 
не хотели бы заниматься администрированием компьютера. Это заключение заста¬ 
вило многих исследователей вспомнить о системах разделения времени с «глупы¬ 
ми» терминалами (теперь вежливо называемыми «тонкими» клиентами), вполне 
соответствующих современным представлениям о терминалах. Системах \Уіпсіо\ѵз 
была одним из шагов в этом направлении, но Х-сервер все еще остается сложной 
системой, состоящей из нескольких мегабайтов программного обеспечения, которое 
требуется периодически обновлять. Идеалом была бы высокопроизводительная 
интерактивная компьютерная система, в которой машина пользователя вообще не 
имела бы программного обеспечения. И что интересно, такая цель достижима. Ниже 
мы опишем одну такую систему, разработанную исследователями корпорации Зип 
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МісгозузСешз и Стэнфордского университета. Сегодня эта система распространя¬ 
ется на коммерческой основе корпорацией 5ші [295]. 

Система получила название 5ЫМ (Зіаіеіезз Ьо\ѵ-1еѵе1 Іпіегіасе МасЬіпе — 
машина низкоуровневого интерфейса без состояний). В основе идеи лежит тради¬ 
ционная схема централизованного разделения времени, показанная на рис. 5.39. 
Клиентские машины представляют собой просто «глупые» растровые дисплеи 
с разрешением 1280x1024 точки, с клавиатурой и мышью, но без программного 
обеспечения, устанавливаемого пользователем. Все это в большой степени со¬ 
ответствует духу старых «интеллектуальных» алфавитно-цифровых терминалов, 
у которых не было никакого программного обеспечения, а только некоторое коли¬ 
чество программно-аппаратных средств для интерпретации Е5С-последователь- 
ностей. Терминалы такого типа, не обладающие мощными вычислительными спо¬ 
собностями, называются «тонкими» клиентами. 


Компьютерный центр ^ 



«Тонкий» клиент 


Простейшая модель, состоящая в передаче сервером растровых изображений 
по сети «тонким» клиентам, не работает. Для этого потребуется пропускная спо¬ 
собность для каждой выделенной линии около 2 Гбайт/с, что слишком много для 
современных сетей. Следующая по простоте модель, заключающаяся в хранении 
образа экрана в буфере кадра на терминале и обновлении экрана локально, явля¬ 
ется намного более обещающей. В частности, если центральный сервер будет хра¬ 
нить копию буфера кадра каждого терминала и посылать только обновления (из¬ 
менения), требуемая пропускная способность будет уже не столь велика. Таким 
образом работают «тонкие» клиенты системы 5ЫМ. 

В отличие от Х-протокола, состоящего из сотен сложных сообщений для уп¬ 
равления окнами, рисования геометрических фигур и отображения текста раз¬ 
личными шрифтами, у протокола 5ЫМ есть всего пять сообщений от сервера 
к терминалу, перечисленные в табл. 5.6 (помимо них имеется еще небольшое 
количество не приведенных в таблице управляющих сообщений). Сообщение 
5ЕТ просто заменяет прямоугольник в буфере кадра новыми пикселами. Каждый 
заменяемый пиксел требует трех байтов в сообщении, чтобы указать его полное 
(24-разрядное) значение цвета. В принципе этого сообщения достаточно, чтобы 
выполнить всю работу. Остальные сообщения представляют собой всего лишь 
оптимизацию. 
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Таблица 5.6. Сообщения от сервера к терминалу протокола Зим 
Сообщение Значение 

ЗЕТ Обновить прямоугольник новыми пикселами 

РІІ_І_ Заполнить прямоугольник пикселами одного значения 

ВІТМАР Растянуть растровое изображение, чтобы заполнить прямоугольник 

СОРУ Копировать прямоугольник из одной части буфера в другую 

СЗСЗ Преобразовать прямоугольник в НОВ из телевизионной системы цветов (ѴІІѴ) 

Сообщение РШ. заполняет целый прямоугольник пикселами одного значения. 
Эта команда используется для заполнения однородных фоновых поверхностей. 
Сообщение ВІТМАР заполняет целый прямоугольник, повторяя одно растровое изоб¬ 
ражение, содержащееся в сообщении. Эта команда полезна для заполнения моза¬ 
ичного фона. 

Сообщение СОРУ велит терминалу скопировать прямоугольник из одной части 
экранного буфера в другую. Она наиболее всего полезна при скроллинге экрана 
и перемещении окон. 

Наконец, сообщение С5С5 преобразует цвета из системы УЕІѴ, используемой 
в США в телевизионной системе ИТ5С, в систему КСВ, применяемую компью¬ 
терными мониторами. В первую очередь эта команда может использоваться при 
передаче необработанного видеокадра от сервера терминалу. Алгоритм преобра¬ 
зования несложен, но занимает много времени, поэтому эту работу лучше пору¬ 
чить терминалам. Если терминалы не будут использоваться для просмотра видео¬ 
формата ИТ5С, то это сообщение не понадобится. 

В целом идея «глупых» «тонких» клиентов оказывается либо работоспособной, 
либо неработоспособной в зависимости от требующейся и доступной производи¬ 
тельности сети и серверов, измерением которой интенсивно занимались Шмидт 
с коллегами [295]. В исследуемом ими прототипе как на участке между серверами 
и коммутатором, так и для соединений между коммутатором и терминалами ис¬ 
пользовалась 100-Мбитная коммутируемая быстрая сеть ЕіЬегпеі. В принципе 
сервер с коммутатором можно было соединить и гигабитной сетью, так как весь 
этот участок находился в центральном вычислительном зале. 

Первые измерения касались вывода эха символа на экран. Каждый введенный 
с клавиатуры символ посылается на сервер, который вычисляет координаты пик¬ 
селов, требующих обновления, чтобы поместить на экран символ в нужную пози¬ 
цию, с правильными цветами и шрифтом. Измерения показали, что для появле¬ 
ния символа на экране требуется 0,5 мс. Для сравнения: на локальной рабочей 
станции из-за буферизации в ядре это время составляет около 30 мс. 

Остальные тесты измеряли производительность системы. При этом пользова¬ 
тели работали с современными интерактивными прикладными программами, та¬ 
кими как АсЬЬе РЬоІозЬор (программа для ретуширования фотографий), АсІоЬе 
Ргатешакег (настольная издательская система) и Иеізсаре (\ѵеЬ-браузер). Было 
замечено, что половина команд пользователей требовала обновления менее 10 000 
пикселов, что в несжатом виде составляет 30 000 байт. На скорости 10 Мбит/с для 
передачи по кабелю 10 000 пикселов требуется 2,4 мс. Еще 2,7 мс нужно для по¬ 
мещения их в буфер кадра по прибытии, итого 5,1 мс (это время может немного 
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варьироваться в зависимости от обстоятельств). Поскольку время реакции чело¬ 
века составляет около 100 мс, обновления кажутся практически мгновенными. 
Даже изменения больших объемов данных воспринимались бы как почти мгно¬ 
венные. Более того, при использовании сжатия для более чем 85 % обновлений эк¬ 
рана требуется передача менее 30 000 байт. 

Эксперименты были повторены с 10-Мбитной сетью, 1-Мбитной сетью и 128- 
Кбитной сетью. При использовании 10-Мбитной сети система была практически 
мгновенной. На 1-Мбитной сети результаты оставались хорошими. 128-Кбитная 
сеть оказалась слишком медленной для таких задач. Поскольку соединения с про¬ 
пускной способностью 1 Мбит/с становятся все более распространенными благо¬ 
даря сетям кабельного телевидения и АБ5Б (Авушшеігіс Біфіаі ЗиЬзсгіЬег Боор — 
асимметричная цифровая абонентская линия), то, похоже, что эта технология уже 
может применяться как для домашних пользователей, так и для деловых клиентов. 


Управление режимом энергопотребления 

Первый универсальный электронный компьютер Е№АС (Еіесігопіс Иитегісаі 
Іп1е§га1ог апсі Саісиіаіог — электронный цифровой интегратор и калькулятор) со¬ 
стоял из 18 000 электронных ламп и потреблял 140 кВт. В результате счета за элек¬ 
тричество были довольно высоки. После изобретения транзистора потребление 
электроэнергии снизилось на несколько порядков, в результате чего компьютер¬ 
ная промышленность потеряла интерес к экономии электроэнергии. Однако сегод¬ 
ня по различным причинам управление режимом электропитания снова оказалось 
в центре внимания, и занимается этим в большой степени операционная система. 

Начнем с настольного персонального компьютера. Обычный настольный персо¬ 
нальный компьютер содержит 200-ваттный блок питания (КПД такого блока пита¬ 
ния составляет около 85 %. Это означает, что около 15 % энергии преобразуется 
в тепло уже в блоке питания). Если одновременно включить питание 100 млн таких 
машин по всему миру, то вместе они будут использовать около 20 ГВт. Эта мощность 
примерно соответствует мощности 20 атомных электростанций среднего размера. 
Если бы потребление электроэнергии компьютерами можно было уменьшить 
вдвое, то мы могли бы закрыть 10 атомных электростанций. С точки зрения охраны 
окружающей среды закрытие 10 атомных электростанций (или эквивалентного 
количества электростанций, работающих на сжигаемом топливе) является большим 
достижением, и за это стоит побороться. 

Другая область, где потребление электроэнергии также является важным во¬ 
просом, — это переносные компьютеры, питаемые от батарей, включая, среди про¬ 
чих, ноутбуки, лэптопы, палмтопы и мюЬ-блокноты. Основой проблемы является 
то, что батареи не могут удерживать количество энергии, достаточное для долгой 
работы компьютера. Обычное время, на которое хватает заряда аккумуляторов, не 
превышает нескольких часов. Несмотря на широкомасштабные исследования, про¬ 
водимые различными компаниями, специализирующимися в области производ¬ 
ства электрических элементов, прогресс в этой области практически нулевой. Для 
индустрии, привыкшей к удвоению производительности через каждые 18 месяцев 




406 


Глава 5. Ввод-вывод 


(закон Мура), полное отсутствие прогресса выглядит как нарушение законов 
физики. В результате создание компьютеров, потребляющих меньше энергии, что¬ 
бы существующих батарей хватало на более долгий срок, является задачей номер 
один для многих исследователей. Как мы увидим, операционная система здесь 
играет основную роль. 

К снижению потребления электроэнергии существует два основных подхо¬ 
да. Первый из них заключается в выключении операционной системой тех частей 
компьютера (главным образом, устройств ввода-вывода), которые не используют¬ 
ся в данный момент. Второй подход состоит в снижении потребления энергии при¬ 
кладными программами, возможно, за счет снижения качества восприятия пользо¬ 
вателем. Мы по очереди рассмотрим оба подхода, но сначала скажем несколько 
слов о технических средствах компьютера с точки зрения энергопотребления. 


Аппаратный аспект 

Электрические элементы подразделяются на два основных типа: одноразовые и пе¬ 
резаряжаемые (аккумуляторы). Одноразовые электрические элементы (например, 
ААА, АА и О) могут использоваться для питания небольших портативных устройств 
размером с ладонь, но у них недостаточно энергии, чтобы питать лэптопы с боль¬ 
шими яркими экранами 1 . Аккумуляторные батареи, напротив, могут хранить до¬ 
статочно энергии для питания лэптопов в течение нескольких часов. Обычно для 
этой цели использовались никель-кадмиевые элементы, но в последнее время кад¬ 
мий в этих элементах был заменен металлическими гидридами, в результате чего 
время жизни аккумуляторов увеличилось, и, кроме того, новые элементы наносят 
меньший ущерб окружающей среде, когда их в конце концов приходится выбра¬ 
сывать. Литиевые ионные батареи еще лучше, так как их можно перезаряжать, не 
дожидаясь полной разрядки, но их емкость также ограничена. 

Основной метод, предпринимаемый многими производителями компьютеров 
для продления жизни батарей, состоит в проектировании центрального процессо¬ 
ра, памяти и устройств ввода-вывода, способных находиться в нескольких режи¬ 
мах энергопотребления: включенном, режиме ожидания, режиме глубокой «зим¬ 
ней спячки», называемой также гибернацией, и в выключенном состоянии. Чтобы 
устройством можно было пользоваться, оно должно быть включено. Если устрой¬ 
ство не используется в течение короткого интервала времени, оно может быть пе¬ 
реведено в режим низкого энергопотребления. Если интервал времени, в течение 
которого устройство не используется, более долгий, потребление энергии устрой¬ 
ством может быть снижено в еще большей степени. Обычно чем в более глубокую 
«спячку» переводится устройство, тем больше времени требуется, чтобы вывести 
его оттуда. Наконец, когда устройство выключено, оно не потребляет энергии вовсе. 
Не у всех устройств есть все эти состояния, но если устройство поддерживает режи¬ 
мы низкого энергопотребления, то именно операционная система должна управ¬ 
лять переводом устройства из одного режима в другой в соответствующий момент. 

1 Дело, скорее, в размерах элементов, а не в одноразовости. Обычно, наоборот, аккумуляторы могут 
хранить чуть меньше заряда, чем одноразовые элементы. В противном случае все «Энерджайзеры» и 
«Дюраселы» были бы перезаряжаемыми. Аккумуляторы просто удобнее и дешевле с учетом возмож¬ 
ности их перезарядки. — Примеч. перев. 
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У некоторых компьютеров есть две или даже три кнопки питания. Одна из них 
может перевести весь компьютер в режим низкого энергопотребления, из которого 
он может быть быстро выведен простым нажатием любой клавиши или перемеще¬ 
нием мыши. Другая кнопка может переводить компьютер в более глубокую «спяч¬ 
ку», возвращение в активное состояние из которой может занять значительно боль¬ 
ше времени. В обоих случаях эти кнопки обычно всего лишь посылают особые 
сигналы операционной системе, которая выполняет все необходимые действия. 
В некоторых странах закон требует, чтобы все электрические устройства в целях 
безопасности оснащались механическим выключателем электропитания. Для со¬ 
ответствия этому закону может понадобиться еще одна кнопка. 

Управление режимом энергопотребления поднимает ряд вопросов, с которы¬ 
ми операционная система должна иметь дело. Среди этих вопросов такие: какие 
устройства могут управляться операционной системой? Есть ли у этих устройств 
два состояния, включенное и выключенное или имеются еще и промежуточные? 
Сколько мощности сберегается в различных режимах низкого энергопотребления? 
Расходуется ли энергия на перезапуск (разгон) устройства? Должен ли сохранять¬ 
ся контекст при переводе устройства в режим низкого энергопотребления? Сколь¬ 
ко времени занимает активизация устройства? Ответы на все эти вопросы различ¬ 
ны для разных устройств, поэтому операционная система должна уметь работать 
с широким спектром возможных вариантов и комбинаций. 

Многие исследователи изучали лэптопы, пытаясь понять, на что тратится энер¬ 
гия. Ли с сотоварищами в 1994 году произвел измерения энергопотребления в раз¬ 
личных режимах работы и пришел к выводу, проиллюстрированному в табл. 5.7 
[206]. Лорх и Смит в 1998 году произвели замеры на других машинах и полу¬ 
чили несколько отличные результаты, также показанные в табл. 5.7 [215]. Вайзер 
с коллегами в 1994 году тоже занимались сходными измерениями, но эта группа 
исследователей не опубликовала численных значений [357]. Они просто заявили, 
что основными потребителями электроэнергии в переносных компьютерах (в по¬ 
рядке убывания) являются экран, жесткий диск и центральный процессор. Хотя 
результаты, полученные разными исследователями, и не соответствуют друг дру¬ 
гу в точности, возможно потому, что использовались различные марки компьюте¬ 
ров, тем не менее ясно, что именно экран, жесткий диск и центральный процессор 
являются теми устройствами, потребление энергии которыми следует пытаться 
снизить. 


Таблица 5.7. Энергопотребление различных частей лэптопа 


Устройство 

Ли и его коллеги (1994) 

Лорх и Смит (1998) 

Дисплей 

68% 

39% 

Центральный процессор 

12% 

18% 

Жесткий диск 

20% 

12% 

Модем 


6% 

Звуковая плата 


2% 

Память 

0,5% 

1 % 

Другое 


22% 
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Аспект операционной системы 

Операционная система играет ключевую роль в управлении режимом энергопот¬ 
ребления. Она управляет всеми устройствами, поэтому ей приходится решать, ка¬ 
кое устройство и когда выключать. Если выключаемое устройство потребуется 
снова в течение короткого интервала времени, выключения устройства будут лишь 
приводить к раздражающим задержкам при его включении. С другой стороны, если 
операционная система будет слишком долго ждать, прежде чем выключить уст¬ 
ройство, это приведет к напрасной растрате электроэнергии. 

Хитрость состоит в том, чтобы найти алгоритмы, позволяющие операционной 
системе принимать правильные решения, касающиеся энергопотребления. Слож¬ 
ность в том, что понятие «правильного» решения в большой степени субъективно. 
Для одного пользователя может оказаться вполне приемлемым, если после того, 
как он в течение 30 с не использует компьютер, потребуется 2 с, чтобы получить 
ответ на нажатую клавишу. Другой же пользователь, оказавшись в такой же ситуа¬ 
ции, станет ругаться до посинения. Если у компьютера не будет устройства аудио¬ 
ввода, он не сможет отличить одного пользователя от другого. 

Дисплей 

Рассмотрим теперь устройства, являющиеся самыми крупными потребителями 
электроэнергии, чтобы понять, что можно сделать с каждым из них. Больше всех 
устройств электроэнергии потребляет дисплей. Чтобы изображение было ярким 
и контрастным, экран должен иметь подсветку, а для этого требуется значитель¬ 
ная энергия. Многие операционные системы пытаются сберегать энергию, отклю¬ 
чая дисплей, когда в течение определенного интервала времени не наблюдается 
активности со стороны пользователя. Обычно пользователь может сам задать зна¬ 
чение интервала времени, после которого следует выключать дисплей. Таким обра¬ 
зом, пользователь может сам решить этот вопрос, выбирая между часто гаснущим 
дисплеем и быстро садящимися аккумуляторами. Из этого режима пониженного 
энергопотребления дисплей может быть выведен обратно в активное состояние 
практически мгновенно нажатием одной клавиши, при этом изображение регене¬ 
рируется из видеопамяти. 

Один вариант усовершенствования был предложен Флинном и Сатьянарайя- 
наном [117]. Они предложили разделить экран на несколько отдельных зон, пи¬ 
тание для которых подавалось бы отдельно. На рис. 5.40 экран разбит штриховы¬ 
ми линиями на 16 зон. Когда курсор находится в окне 2, как показано на рис. 5.40, а, 
должны светиться только четыре зоны в правом нижнем углу. Остальные 12 зон 
могут оставаться темными, сохраняя, таким образом, 3/4 потребляемой экраном 
энергии. 

Когда пользователь перемещает курсор на окно 1, зоны окна 2 могут быть за¬ 
темнены, а зоны, на которых отображается окно 1, должны быть включены. Одна¬ 
ко так как окно 1 накрывает 9 зон, требуется больше энергии. Если оконный ме¬ 
неджер знает о существовании энергетических зон экрана, он может автоматически 
переместить окно 1 так, чтобы оно помещалось в четыре зоны, как показано на 
рис. 5.40, б. Чтобы было возможно снизить потребление энергии с 9/16 полной мощ¬ 
ности до 4/16 полной мощности, менеджер окон должен разбираться в вопросах 
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экономии электроэнергии или выполнять команды, получаемые от другой части 
операционной системы, занимающейся энергопотреблением. Еще более изощрен¬ 
ной была бы возможность освещать частично окно, которое не содержит инфор¬ 
мации на всей своей площади, например, у окна, содержащего короткие строки 
текста, можно не освещать правую часть. 
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Рис. 5.40. Использование зон подсветки экрана: когда выбирается окно 2, 
оно не перемещается (а); когда выбирается окно 1, оно перемещается, 
чтобы уменьшить число подсвечиваемых зон (б) 


Жесткий диск 

Следующим главным «злодеем» является жесткий диск. Он потребляет значитель¬ 
ное количество энергии для поддержания высокой скорости вращения даже при 
отсутствии обращений к нему. Многие компьютеры, особенно лэптопы, останав¬ 
ливают жесткий диск, если в течение определенного времени к нему нет обраще¬ 
ний. Когда он оказывается нужен, диск запускается снова. К сожалению, время 
раскрутки диска занимает несколько секунд, что составляет весьма ощутимую для 
пользователя задержку. 

Кроме того, на раскрутку диска требуется дополнительная энергия. В резуль¬ 
тате если диск останавливать и раскручивать слишком часто, то может оказаться, 
что энергетически выгоднее позволить диску вращаться постоянно, чем выключать 
и включать его снова. Каждый диск обладает характерным временем варьирую¬ 
щимся от 5 до 15 с. Предположим, что следующее обращение к диску ожидается 
через интервал времени I. Если I < Г Л то на поддержание вращения диска потре¬ 
буется меньше энергии, чем на его последующую раскрутку. Если же I > Т л , то вы¬ 
годнее окажется остановить диск, а затем запустить его снова. При способности 
хорошо предсказывать (на основе времени последних обращений к диску), когда 
произойдет следующее обращение к диску, операционная система могла бы опти¬ 
мально экономить электроэнергию. На практике, однако, в большинстве систем 
применяется консервативная политика выключения устройств после истечения 
определенного интервала времени, в течение которого к ним не было обращений. 

Другой способ сохранения энергии диска заключается в поддержании большо¬ 
го дискового кэша в оперативной памяти. Если нужный блок находится в памяти, 
обращения к диску при чтении этого блока не происходит, в результате чего диск 
можно не раскручивать. Аналогично, запись на диск также может буферизировать- 
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ся в кэше. При этом диск может оставаться выключенным, пока не переполнится 
кэш или не понадобится блок, отсутствующий в кэше 1 . 

Еще один способ избежать излишних запусков жесткого диска состоит в пре¬ 
доставлении операционной системой информации о состоянии диска работающей 
программе. Некоторые программы производят периодические операции записи на 
диск, которые можно пропустить или отложить. Например, текстовый процессор 
может быть настроен на сохранение редактируемого файла через определенные 
интервалы времени. Если текстовый процессор знает, что диск в данный момент 
выключен, он может отложить операцию сохранения до того момента, когда диск 
будет включен или просто подождать некоторое время. 

Центральный процессор 

Центральный процессор также может находиться в различных режимах энерго¬ 
потребления. Центральный процессор лэптопа может быть программно переведен 
в режимах низкого энергопотребления, при котором он практически не потреб¬ 
ляет энергии. В этом режиме он не выполняет никаких действий. Вывести из 
этого режима его может любой сигнал прерывания. Таким образом, если у цент¬ 
рального процессора нет текущих дел, он может перейти в режим низкого энерго¬ 
потребления. 

На многих компьютерах напряжение, потребляемое центральным процессо¬ 
ром, его частота и потребляемая мощность связаны между собой. Напряжение 
питания центрального процессора часто можно уменьшить программно. При 
этом (приблизительно пропорционально) снизится его тактовая частота, зато 
(пропорционально квадрату напряжения) снизится энергопотребление. Напри¬ 
мер, снижение напряжения питания центрального процессора вдвое уменьшит его 
производительность также в два раза, зато энергии он будет потреблять в четыре 
раза меньше. 

Это свойство может использоваться программами с хорошо известными сро¬ 
ками выполнения определенных операций, например программами просмотра 
мультимедиа, которым требуется через каждые 40 мс распаковать и отобразить 
один кадр. Однако если программе удается выполнить эту операцию быстрее, она 
может остаток временного интервала провести в режиме низкого энергопотреб¬ 
ления процессора. Предположим, центральный процессор потребляет мощность, 
равную х Вт, при работе на полной мощности, и х/А Вт при половинной скорости. 
Если программа может распаковать и отобразить кадр за 20 мс, операционная сис¬ 
тема может на остальные 20 мс полностью отключить процессор, в результате чего 
среднее потребление энергии процессором снизится вдвое. Однако операционная 
система может на все 40 мс снизить вдвое напряжение питания процессора, в ре¬ 
зультате чего процесс распаковки и вывода кадра на экран займет все 40 мс, зато 
энергии центральный процессор потребит меньше вчетверо (рис. 5.41). В обоих 
случаях выполняется один и тот же объем работ, но на рис. 5.41,6 на это потребу¬ 
ется в два раза меньше энергии. 

1 При этом снизится надежность, так как на диске данные хранить все-таки надежнее, чем в памяти. — 
Приліеч. перев. 
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Рис. 5.41 . Работа на полной скорости (а); снижение напряжения вдвое уменьшает в два раза 
частоту процессора, а потребляемую мощность вчетверо (б) 

В схожей ситуации, если пользователь вводит один символ в секунду, а для 
обработки символа требуется 100 мс, операционная система может снизить ско¬ 
рость процессора в 10 раз. Подводя итоги, можно сказать, что медленная работа 
является более эффективной с энергетической точки зрения. 

Оперативная память 

Для энергосбережения при работе с памятью возможны два подхода. Во-первых, 
можно периодически сохранять и выключать кэш. Его всегда можно перезагрузить 
из оперативной памяти без потерь информации. Перезагрузка может выполнять¬ 
ся автоматически и достаточно быстро, таким образом, данный вариант «сна» не 
является глубоким. 

Более радикальный метод заключается в сохранении содержимого оператив¬ 
ной памяти на диске, после чего может быть выключена сама оперативная память. 
Этот метод представляет собой уже глубокую «спячку», так как перезагрузка мо¬ 
жет занять довольно существенное время, особенно если диск также останавлива¬ 
ется. Когда память выключена, то и центральный процессор стоит выключить, так 
как обрабатывать ему будет практически нечего (кроме ПЗУ). При этом прерыва¬ 
ние, активирующее центральный процессор, должно обрабатываться в ПЗУ, так 
как ОЗУ будет в этот момент выключено. Несмотря на довольно значительные 
накладные расходы по перезапуску, выключение оперативной памяти на длитель¬ 
ный период времени (например, несколько часов) может быть оправдано, если 
перезапуск за несколько секунд оказывается предпочтительнее перезагрузки всей 
операционной системы с диска, что может занять около минуты или даже не¬ 
сколько минут. 

Беспроводная связь 

В последнее время появляется все большее число переносных компьютеров, со¬ 
единенных с внешним миром (например, с Интернетом) при помощи беспровод¬ 
ной связи. Требующиеся для этого радиопередатчики и радиоприемники часто 
оказываются самыми мощными потребителями энергии. В частности, если радио¬ 
приемник находится в постоянно включенном состоянии, чтобы прослушивать 
поступающие сигналы, заряд аккумуляторов может иссякнуть довольно быстро. 
С другой стороны, если выключить радиоприемник после одной минуты простоя, 
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пришедшее сообщение может оказаться пропущенным, что, конечно, крайне не¬ 
желательно. 

Одно эффективное решение этой проблемы было предложено в 1998 году Кра- 
вецом и Кришнаном [186]. В основу этого решения положен то? факт, что мобиль¬ 
ные компьютеры общаются с неподвижными базовыми станциями, обладающими 
большими объемами оперативной памяти и дискового пространства, а также не 
связанными ограничениями в потреблении энергии. Их предложение заключает¬ 
ся в том, что мобильный компьютер, собираясь выключить радио, передает базо¬ 
вой станции соответствующее сообщение. Получив его, базовая станция буфери¬ 
зирует все сообщения, адресованные мобильному компьютеру на своем диске. 
Спустя некоторое время, включив снова свою радиостанцию, мобильный компь¬ 
ютер первым делом сообщает об этом базовой станции. В ответ она присылает ему 
все сообщения, накопившиеся за это время. 

Исходящие сообщения, сформированные в период, когда радио отключено, 
буферизируются на мобильном компьютере. Если буферу угрожает переполне¬ 
ние, радиопередатчик включается и сообщения, стоящие в очереди, передаются на 
базовую станцию. 

Когда следует выключать радио? Можно разрешить принимать подобное ре¬ 
шение пользователю или прикладной программе. Другой вариант состоит в отклю¬ 
чении радиостанции через несколько секунд простоя. Когда следует снова вклю¬ 
чить радиопередатчик? Опять же, решение может принимать пользователь или 
прикладная программа, либо включение может производиться также периодичес¬ 
ки для проверки приходящих сообщений или для передачи сообщений, поставлен¬ 
ных в очередь. Кроме того, передатчик должен включаться при угрозе переполне¬ 
ния буфера. Возможны также и другие решения. 

Управление температурным режимом 

Проблема управления температурным режимом несколько отличается от пробле¬ 
мы энергосбережения, тем не менее этот вопрос также имеет отношение к энер¬ 
гии. Из-за своей высокой частоты современные центральные процессоры очень 
сильно греются. Настольные машины обычно оснащаются внутренним электричес¬ 
ким вентилятором, сдувающим горячий воздух с шасси. Поскольку для настольных 
компьютеров снижение энергопотребления не является вопросом жизни и смер¬ 
ти, вентилятор обычно включен постоянно. 

С лэптопами ситуация совершенно иная. Операционная система должна по¬ 
стоянно следить за температурой узлов компьютера. Когда температура начинает 
приближаться к максимально допустимому значению, у операционной системы 
есть выбор. Она может включить вентилятор, который шумит и потребляет энер¬ 
гию. В качестве альтернативы она может уменьшить энергопотребление, снизив 
освещенность экрана, уменьшив тактовую частоту процессора, чаще останавливая 
винчестер и т. д. 

Пользователь также может принять участие в принятии решения. Например, 
он может заранее указать, что возражает против шума вентилятора, в результате 
операционной системе останется только снижать энергопотребление. 
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Управление состоянием батарей 

Давным-давно батареи просто давали электрический ток, пока не иссякали, после 
чего их работа прекращалась. Сегодня все стало несколько сложнее и интереснее. 
В лэптопах сегодня применяются «умные» батареи, способные общаться с опера¬ 
ционной системой. Получив запрос от операционной системы, они могут сообщить 
такие сведения, как максимальное напряжение, текущее напряжение, максималь¬ 
ный заряд, текущий заряд, максимальная скорость разрядки, текущая скорость 
разрядки и т. д. У большинства лэптопов имеются программы, которые можно за¬ 
пустить, чтобы отобразить все эти параметры. «Умные» батареи могут также из¬ 
менять различные рабочие параметры под управлением операционной системы. 

У некоторых лэптопов имеется несколько батарей. Когда операционная систе¬ 
ма обнаруживает, что одна из батарей скоро разрядится, она должна организовать 
корректное переключение на другую батарею. Когда же у последней батареи закан¬ 
чивается заряд, операционная система должна предупредить пользователя и вы¬ 
полнить принудительное завершение работы, чтобы гарантировать, что файловая 
система не повреждена. 

Интерфейс драйвера 

В системе \Ѵт<Зо\ѵз имеется тщательно продуманный механизм управления энер¬ 
гопотреблением, называемый АСРІ (АйѵапсесІ Зузіеш Сопй§ига1юп апсі Ро\ѵег 
Іпіегіасе — усовершенствованный интерфейс конфигурирования системы и уп¬ 
равления энергопотреблением). Операционная система может посылать любому 
драйверу, поддерживающему данный интерфейс, команды с требованием сооб¬ 
щить возможности его устройств и их текущие состояния. Эта способность особен¬ 
но важна в комбинации с использованием стандарта Р1и§ апсі Ріау, так как сразу пос¬ 
ле загрузки операционная система даже не знает, какие устройства присутствуют 
в компьютере, не говоря уже об их свойствах, касающихся энергопотребления или 
возможности управлять им. 

Операционная система также может посылать драйверам команды, приказы¬ 
вая им снизить уровни энергопотребления (основываясь, естественно, на инфор¬ 
мации, полученной при загрузке). 

Частичное функционирование 

До сих пор мы рассматривали те способы, которыми операционная система может 
снизить потребление энергии различными видами устройств. Однако к решению 
данной проблемы есть и другой подход: велеть программе использовать меньше 
энергии, даже если это означает снижение уровня восприятия пользователя, 
называемое в данном контексте деградацией (лучше ухудшение восприятия, чем 
его полное отсутствие, наступающее после полного истощения аккумуляторов). 
Обычно программа получает такое сообщение, когда заряд батарей оказывается 
ниже определенного уровня. В этом случае прикладная программа может выбрать 
между снижением производительности для продления жизни батарей и сохране¬ 
нием производительности с риском нехватки энергии. 

Таким образом, возникает вопрос: как может прикладная программа снизить 
свою производительность для экономии энергии? Этот вопрос был рассмотрен 
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Флинном и Сатьянарайянаном [117]. Они предложили четыре примера экономии 
энергии с помощью снижения производительности. Мы рассмотрим их ниже. 

В данном исследовании информация предоставляется пользователю в различ¬ 
ном виде. Когда снижения производительности нет, пользователю предоставляет¬ 
ся максимально качественная информация. При снижении производительности 
качество воспроизведения (точность) информации, предоставляемой пользова¬ 
телю, оказывается хуже, чем это возможно. Мы кратко рассмотрим этот вопрос 
на примерах. 

Для измерения используемой энергии Флинн и Сатьянарайянан разработа¬ 
ли программный инструмент, названный ими Ро\ѵег5соре. Этот инструмент пока¬ 
зывает мощность, потребляемую программой. Для его использования компьютер 
должен быть подключен к внешнему источнику питания через управляемый про¬ 
граммно цифровой универсальный электроизмерительный прибор. При помощи 
этого прибора программное обеспечение может узнать силу тока, поступающего 
от источника питания, и таким образом определить мгновенную мощность, по¬ 
требляемую компьютером. Ро\ѵег5соре периодически записывает в файл текущее 
состояние счетчика команд и соответствующее ему значение потребляемой мощ¬ 
ности. По окончании работы программы этот файл анализируется, в результате 
чего можно узнать значения потребляемой мощности для каждой работающей на 
компьютере процедуры. Эти измерения образовали основу их наблюдений. Про¬ 
граммные методы энергосбережения сравнивались с аппаратными, которые так¬ 
же применялись. 

Первой программой, для которой были произведены измерения, стала програм¬ 
ма воспроизведения видео. В нормальном режиме она воспроизводит 30 кадров 
в секунду в полном разрешении и цвете. Одна из форм снижения качества вос¬ 
произведения состоит в отображении видео в черно-белом изображении. Другая 
форма заключается в уменьшении частоты вывода кадров, что приводит к мерца¬ 
нию и подергиванию изображения. Еще одна форма снижения качества воспроиз¬ 
ведения заключается в уменьшении числа пикселов, выводимых на экран в каж¬ 
дом кадре, либо за счет уменьшения размеров отображаемого кадра, либо за счет 
снижения разрешения изображения. Экономия энергии составила в данном слу¬ 
чае около 30 %. 

Второй исследуемой программой был распознаватель речи. Эта программа 
сохраняла отсчеты сигнала микрофона. Полученный квантованный сигнал мог 
анализироваться либо на лэптопе, либо посылаться по радио для анализа ста¬ 
ционарному компьютеру. При этом экономилась энергия, затрачиваемая цент¬ 
ральным процессором, но расходовалась дополнительная энергия на радиосвязь. 
Деградация в данном случае представляла собой использование словаря мень¬ 
шего размера и более простой акустической модели. В данном случае выигрыш 
составил около 35 %. 

Следующим примером была программа просмотра карты, получающая карту 
по радио. Деградация заключалась либо в уменьшении размеров отображаемой 
карты, либо в том, что программа велела удаленному серверу опускать незначи¬ 
тельные дороги, таким образом снижая количество битов, требуемых для переда¬ 
чи. Здесь также экономия составила около 35 %. 
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Четвертый эксперимент заключался в передаче ] Р Е С - из об ражен ий \ѵеЬ-бра- 
узеру. Стандартом ^ЕС поддерживаются различные алгоритмы, что позволяет 
выбирать между качеством изображения и размерами файла. В данном случае 
средний выигрыш составил всего 9 %. Тем не менее данные эксперименты показа¬ 
ли, что, согласившись на некоторое снижение качества работы программы, пользо¬ 
ватель может работать дольше с теми же аккумуляторами. 


Исследования ввода-вывода 

Проблемам ввода-вывода было посвящено много исследований, однако большая 
их часть была нацелена скорее на изучение конкретных устройств, нежели на ввод- 
вывод в целом. 

Одним из рассматриваемых вопросов являются диски. В старых алгоритмах 
используется уже не применимая ныне модель диска, поэтому Уортингтоном и 
группой исследователей была рассмотрена модель, соответствующая современным 
дискам [363]. Система КАШ в настоящее время находится в центре внимания 
исследователей, изучающих различные аспекты данной системы. Альварес с груп¬ 
пой ученых занимались исследованием улучшения устойчивости к сбоям [10]. 
Этим же вопросом занимались Блаум и его коллеги [35]. Другие исследователи 
изучали идею использования в системе КАШ параллельных контроллеров [51]. 
Третья группа исследователей описала прогрессивную систему КАШ, которую 
они построили для Неѵѵіогг Раскагб [358]. Для большого количества дисков требу¬ 
ется тщательное параллельное планирование, что также исследовалось [64, 170]. 
Некоторые исследователи настаивают на использовании холостого времени после 
завершения операции поиска цилиндра, но до того, как нужный сектор окажется 
под головкой [219]. Еще более обещающими выглядят исследования электроме¬ 
ханических накопителей, не имеющих вращающихся деталей [136, 53], а также 
голографических накопителей [254]. Интересной новой технологией являются 
магнитооптические диски [229]. 

Идея использования 5ЫМ-терминалов представляет собой современную вер¬ 
сию старой системы разделения времени, в которой все вычисления производятся 
централизованно, а пользователям предоставляются терминалы, просто управля¬ 
ющие дисплеем, клавиатурой и мышью [295]. Основное отличие от старой систе¬ 
мы разделения времени состоит в том, что вместо того, чтобы соединять терминал 
с компьютером через модем со скоростью 9600 бит/с, используется 10-мегабитная 
сеть ЕіЬегпеІ, обеспечивающая достаточную пропускную способность для полно¬ 
го графического интерфейса со стороны пользователя. 

Графические интерфейсы пользователя стали в настоящее время практически 
стандартами, но тем не менее в этой сфере работы продолжаются, например в облас¬ 
ти речевого ввода [221, 222, 305, 335]. Внутренней структуре графического интер¬ 
фейса пользователя также посвящены исследования [327]. 

При наличии огромного количества лэптопов у кибернетиков и очень короткого 
времени жизни батарей неудивительно, что проблема энергосбережения также явля¬ 
ется предметом интенсивных исследований [107, 117, 186, 198, 214, 217]. 
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Резюме 

Ввод-вывод, хотя им часто пренебрегают, является тем не менее важной темой. 
Существенная часть операционной системы занимается вводом-выводом. Опе¬ 
рация ввода-вывода может выполняться тремя способами. Во-первых, при помо¬ 
щи программного ввода-вывода, при котором центральный процессор вводит или 
выводит каждый байт или слово, находясь в цикле ожидания готовности устрой¬ 
ства ввода-вывода. Второй способ представляет собой управляемый прерывания¬ 
ми ввод-вывод, при котором центральный процессор начинает передачу ввода- 
вывода для символа или слова, после чего переключается на другой процесс, пока 
прерывание от устройства не сообщит ему об окончании операции ввода-вывода. 
Третий способ заключается в использовании прямого доступа к памяти (БМА), 
при котором отдельная микросхема управляет переносом целого блока данных, 
и инициирует прерывание только после окончании операции переноса блока. 

Ввод-вывод можно разбить на четыре уровня иерархии: процедуры обработки 
прерываний, драйверы устройств, независимое от устройств программное обеспе¬ 
чение ввода-вывода и библиотеки ввода-вывода и спулеры, работающие в про¬ 
странстве пользователя. 

Драйверы устройств управляют деталями работы устройств и предоставляют 
однородные интерфейсы к остальной части операционной системы. Независи¬ 
мое от устройств программное обеспечение ввода-вывода занимается буфериза¬ 
цией и сообщением об ошибках. 

Существует большое количество типов дисков, включая магнитные диски, 
системы КАШ и различные типы оптических дисков. Алгоритмы планирования 
перемещения блока головок часто могут улучшить производительность диска, но 
наличие виртуальной геометрии усложняет эту задачу. При помощи объединения 
двух дисков в пару может быть создан надежный носитель данных с определенны¬ 
ми полезными свойствами. 

Часы используются для определения текущего значения реального времени, 
ограничения времени работы процессов, управления сторожевыми таймерами, 
а также сбора статистической информации. 

Алфавитно-цифровые терминалы позволяют вводить специальные управляю¬ 
щие символы с клавиатуры, а вывод на дисплей алфавитно-цифрового терминала 
управляется Е5С-последовательностями. Драйвер клавиатуры может работать как 
в «сыром» режиме, так и в режиме с обработкой, в зависимости от потребностей 
конкретной прикладной программы. Е5С-последовательности при выводе на тер¬ 
минал управляют перемещением курсора, а также позволяют вводить и удалять 
текст с экрана. 

Многие персональные компьютеры используют для вывода графические интер¬ 
фейсы пользователя, основывающиеся на\ѴІМР-парадигме: окнах, пиктограммах, 
меню и указывающем устройстве. Программы, пользующиеся графическим интер¬ 
фейсом пользователя, обычно управляются событиями. Ввод с клавиатуры, мыши, 
а также другие события посылаются на обработку программе. 

Существует несколько типов сетевых терминалов. Один из наиболее популяр¬ 
ных сетевых терминалов работает под управлением оконной системы X \ѴтсІо\ѵ$, 
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на основе которой могут быть построены различные варианты графических 
интерфейсов пользователя. В качестве альтернативы системе X \Уіпс1о\ѵз может 
применяться низкоуровневый интерфейс, просто переносящий необработанные 
пикселы по сети. Эксперименты со 5ІЛМ-терминалами доказали удивительно 
хорошую работоспособность такого метода. 

Наконец, управление энергопотреблением является вопросом номер один для 
портативных компьютеров, так как время работы аккумуляторов сильно ограни¬ 
чено. Операционной системой могут применяться различные методы снижения 
энергопотребления. Кроме того, возможен программный метод экономии энергии 
за счет некоторого снижения качества работы. 


Вопросы 

1. Благодаря прогрессу в сфере технологии производства микросхем стало воз¬ 
можным поместить в одну недорогую микросхему весь контроллер, вклю¬ 
чая всю логику доступа к шине. Как это повлияло на модель, изображенную 
на рис. 1.5? 

2. Основываясь на скоростях, перечисленных в табл. 5.1, скажите, возможно 
ли сканировать на полной скорости документы со сканера на ЕШЕ-диск, 
подключенный к шине І5А? Обоснуйте свой ответ. 

3. На рис. 5.2, б показан один из способов работы с отображаемыми на адрес¬ 
ное пространство памяти устройствами ввода-вывода, даже при наличии 
отдельных шин для памяти и устройств ввода-вывода. Этот способ состоит 
в том, что сначала проверяется шина памяти, а в случае неудачи обращение 
производится к шине ввода-вывода. Умный студент факультета техничес¬ 
кой кибернетики решил усовершенствовать эту модель, предложив распа¬ 
раллелить обращения по двум шинам, чтобы ускорить доступ к устройствам 
ввода-вывода. Что вы думаете о его идее? 

4. У контроллера ЭМА четыре канала. Контроллер способен запрашивать 
32-раэрядное слово через каждые 100 нс. Ответ на запрос занимает столько 
же времени. Насколько быстрой должна быть шина, чтобы не стать узким 
местом системы? 

5. Предположим, что компьютер может обращаться к памяти с операциями 
чтения или записи слова за 10 нс. Также предположим, что при прерывании 
все 32 регистра центрального процессора плюс счетчик и Р5\У сохраняют¬ 
ся в стеке. Какое максимальное количество прерываний в секунду может 
обработать эта машина? 

6. На рис. 5.6, б прерывание не подтверждается до тех пор, пока новый сим¬ 
вол не будет выведен на принтер. Можно ли было подтвердить прерывание 
в самом начале процедуры обработки прерываний? Если да, то укажите при¬ 
чину, по которой это действие выполняется в конце, как показано в тексте. 
Если нет, объясните, почему. 
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7. У компьютера есть трехуровневый конвейер, как показано на рис. 1.6, а. 
На каждом такте процессор выбирает из памяти одну команду с адреса, на 
который указывает счетчик команд, и помещает ее в конвейер, после чего 
значение счетчика команд увеличивается. Предположим, каждая команда 
занимает ровно одно слово процессора. Команды, находящиеся в конвейере, 
продвигаются вперед на одно слово. При прерывании текущее состояние 
счетчика команд сохраняется в стеке, а в счетчик команд заносится адрес 
обработчика прерываний. Затем конвейер смещается на один шаг вправо, 
и первая команда обработчика прерываний попадает в конвейер. Обладает 
ли такая машина точными прерываниями? Обоснуйте свой ответ. 

8. Типичная печатная страница текста состоит из 50 строк по 80 символов 
в каждой. Представьте себе принтер, способный печатать 6 страниц в мину¬ 
ту, причем время вывода на принтер одного символа настолько мало, что им 
можно пренебречь. Имеет ли смысл управлять выводом на этот принтер при 
помощи прерываний, если для печати каждого символа требуется прерыва¬ 
ние, занимающее 50 мкс? 

9. Что такое независимость от устройств? 

10. В каком из четырех уровней программного обеспечения ввода-вывода вы¬ 
полняются следующие действия: 

а) вычисление номеров дорожки, сектора и головки для чтения диска; 

б) запись команд в регистры устройства; 

в) проверка разрешения доступа пользователя к устройству; 

г) преобразование двоичного целого числа в А5СП-символы для вывода на 
печать. 

И. Основываясь на данных табл. 5.3, скажите, чему равна скорость переноса 
данных между диском и контроллером для гибкого диска и жесткого диска? 
Сравните полученные результаты с 56-килобитным модемом и 100-мегабит- 
ной быстрой сетью ЕіЬегпеТ. 

12. Локальная сеть используется следующим образом. Пользователь обращает¬ 
ся к системному вызову, чтобы записать пакеты данных в сеть. Затем опе¬ 
рационная система копирует данные в буфер ядра. После этого данные ко¬ 
пируются в плату сетевого контроллера. После того как все байты попадают 
в контроллер, они посылаются по сети со скоростью 10 Мбит/с. Получающий 
сетевой контроллер сохраняет каждый бит спустя 1 мкс после его отправки. 
Когда последний бит получен, центральный процессор получающего ком¬ 
пьютера прерывается и ядро копирует прибывший пакет в свой буфер, что¬ 
бы исследовать его. Поняв, какому пользователю предназначается пакет, 
ядро копирует данные в пространство пользователя. Если предположить, 
что каждое прерывание и его обработка занимает 1 мс, размер пакетов ра¬ 
вен 1024 байт (не считая заголовков), а копирование одного байта занимает 
1 мкс, то чему будет равна максимальная скорость, с которой один процесс 
может передавать данные другому процессу? Предположите, что отправи- 
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тель блокируется, пока получатель не закончит работу и не отправит обрат¬ 
но подтверждение. Для простоты предположим, что временем получения 
подтверждения можно пренебречь. 

13. Почему файлы, посылаемые на принтер, обычно перед печатью накаплива¬ 
ются на диске? 

14. Чему должен быть равен перекос цилиндров для диска, вращающегося со 
скоростью 7200 об/мин, при времени перемещения головки на соседнюю 
дорожку, равном 1 мс? У диска по 200 секторов по 512 байт на каждой до¬ 
рожке. 

15. Сосчитайте максимальную скорость передачи данных в мегабайтах в секунду 
для диска из предыдущего вопроса. 

16. Система КАШ уровня 3 способна исправлять однобитовые ошибки при 
помощи только одного диска четности. В чем суть системы КАШ уровня 2? 
В конце концов, она также может исправлять только однократные ошибки 
и требует большее число дисков для этого. 

17. Система КАШ может не справиться со своей задачей, если в течение не¬ 
большого интервала времени из строя выйдут сразу два или более дисков. 
Предположим, что вероятность выхода одного диска из строя в течение 
одного часа равна/?. Чему равна вероятность выхода из строя системы КАШ, 
состоящей из к дисков в течение одного часа? 

18. Почему оптические устройства хранения данных обладают более высокой 
плотностью записи данных, чем магнитные накопители? Замечание', этот 
вопрос требует некоторых знаний физики, в частности способа формирова¬ 
ния магнитных полей. 

19. Если контроллер диска записывает получаемые от диска байты в память так 
же быстро, как и получает их, без внутреннего буферирования, будет ли 
польза от чередования секторов? Обоснуйте. 

20. Представьте себе гибкий диск, у которого шаг чередования секторов ра¬ 
вен двум, как на рис. 5.22, в. На каждой дорожке диска восемь секторов по 
512 байт. Скорость вращения диска 300 об/мин. Сколько времени потре¬ 
буется, чтобы прочитать все секторы дорожки в правильном порядке, если 
предположить, что головка диска уже стоит на нужной дорожке, а чтобы сек¬ 
тор 0 переместился под головку, требуется 1/2 оборота диска? Чему равна 
скорость считывания данных? Теперь повторите то же задание для диска без 
чередования с теми же характеристиками. Как сильно снижается скорость 
из-за чередования? 

21. Если на диске применяется двукратное чередование, то требуется ли еще 
применять перекос цилиндров во избежание потерь данных при переходе 
с дорожки на дорожку? Обоснуйте свой ответ. 

22. Фирма выпускает два 5-дюймовых жестких диска, у каждого из которых 
10 000 цилиндров. Новый жесткий диск имеет двойную линейную плот¬ 
ность записи по сравнению с более старым диском. Какие свойства у нового 
диска будут лучше, чем у старого, а какие останутся такими же? 
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23. Производитель компьютеров решает изменить таблицу разделов на жестком 
диске РепНит-компьютера, чтобы предоставить возможность создания бо¬ 
лее четырех разделов. Каковы будут последствия этих изменений? 

24. Драйвер диска получает запросы на чтение/запись к цилиндрам 10, 22, 20, 
2, 40, б и 38. Перемещение блока головок с одного цилиндра на соседний 
занимает б мс. Сколько потребуется времени на перемещение головок при 
использовании алгоритма: 

а) обслуживания в порядке поступления запросов; 

б) обслуживания в первую очередь ближайшего цилиндра; 

в) элеваторного алгоритма (сначала блок головок двигается вверх). 

Во всех случаях начальное положение блока головок на цилиндре 20. 

25. Продавец персональных компьютеров, посещая университет в Юго-Запад¬ 
ном Амстердаме (на юго-западе Амстердама?) для продажи партии компь¬ 
ютеров, заявляет, что его компания приложила существенные усилия по 
ускорению их версии ИШХ. В качестве примера он отмечает, что в их драй¬ 
вере диска применяется элеваторный алгоритм, а также обслуживание оче¬ 
реди запросов к одному цилиндру в порядке секторов. На студента Гарри 
Хакера эго речь производит настолько сильное впечатление, что он покупа¬ 
ет один компьютер. Гарри приносит компьютер домой и пишет программу, 
читающую случайные 10 000 блоков диска. К его изумлению, замеренная им 
производительность идентична той, которой можно было ожидать при 
использовании алгоритма обслуживания запросов в порядке поступления. 
Означает ли это, что продавец лгал? 

26. В обсуждении темы стабильного запоминающего устройства, использующе¬ 
го энергонезависимое ОЗУ, был обойден вниманием следующий момент. 
Что произойдет, если операция стабильной записи будет выполнена, но слу¬ 
чится сбой, прежде чем операционная система сможет записать номер не¬ 
правильного блока в энергонезависимое ОЗУ? Разрушает ли подобное со¬ 
стояние состязаний абстракцию стабильного запоминающего устройства? 
Поясните свой ответ. 

27. На некотором компьютере обработчик прерываний от таймера выполняет 
свои действия за 2 мс (включая накладные расходы по переключению про¬ 
цессов). Прерывания от таймера поступают с частотой 60 Гц. Какая часть 
времени работы центрального процессора расходуется на таймер? 

28. Во многих версиях ТЖІХ значение времени хранится в 32-разрядном целом 
числе, в виде числа секунд от некоторой точки отсчета. Когда перестанет 
хватать 32-разрядного числа для хранения значения времени (год и месяц)? 

29. Некоторым компьютерам, например Интернет-серверам, приходится под¬ 
держивать большое количество линий К.5-232. Для этого существуют платы, 
поддерживающие несколько линий К5-232. Допустим, такая плата содержит 
процессор, проверяющий состояние каждой входной линии (0 или 1), с час¬ 
тотой, в 8 раз большей скорости линии в Бодах. Допустим, что такое измере- 
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ние состояния линии занимает 1 мкс. Сколько линий, работающих со ско¬ 
ростью 3200 бод и способных передавать данные со скоростью 28 000 бит/с, 
может поддержать процессор? Примечание: скорость линии в бодах равна 
количеству изменений сигнала в секунду. Линия со скоростью 3200 бод 
может передавать данные со скоростью 28 000 бит/с, если каждый сигнал 
переносит 9 бит, используя различные амплитуды, частоты и фазы. Сле¬ 
дует отметить, что модемы, работающие со скоростью 56 кбит/с, не исполь¬ 
зуют К8-232. 

30. Почему терминалы, использующие интерфейс К8-232, управляются преры¬ 
ваниями, а терминалы с отображением на память — нет? 

31. Рассмотрим производительность модема со скоростью 56 кбит/с. Драйвер 
посылает один символ, после чего блокируется. После того как символ пе¬ 
редан в линию, происходит прерывание, после чего драйвер разблокирует¬ 
ся и посылает следующий символ и т. д. Какую часть времени центрального 
процессора занимает управление модемом, если обработка прерывания, 
вывод одного символа и блокировка занимают 100 мкс? Предположите, что 
у каждого передаваемого модемом символа имеется один стартовый и один 
столовый бит, а всего символ занимает 10 бит. 

32. Растровый терминал содержит 1280x960 пикселов. Для скроллинга окна 
центральный процессор (или контроллер) должен переместить все строки 
текста вверх, копируя их биты из одной части видеопамяти в другую. Допу¬ 
стим, в окне 60 строк по 80 символов в строке (всего 5280 символов), а каж¬ 
дый символ имеет 8 пикселов в ширину и 16 пикселов в высоту. Сколько 
времени займет скроллинг всего окна, если для копирования одного байта 
требуется 50 нс? Если все строки имеют по 80 символов в длину, чему будет 
равна эквивалентная скорость терминала в бодах? Помещение одного сим¬ 
вола на экран занимает 5 мкс. Сколько строк в секунду может быть выведе¬ 
но в окно? 

33. Получив символ НЕЬ (5ІСІ1МТ), драйвер дисплея очищает всю очередь на 
вывод для этого дисплея. Почему? 

34. Пользователь терминала, использующего интерфейс К8-232, дает редакто¬ 
ру команду удалить слово в строке 5, занимающее позиции с 7 по 12 вклю¬ 
чительно. Какую Е8С-последовательность стандарта АЫ8І должен выдать 
редактор, чтобы удалить слово, если предположить, что курсор не находит¬ 
ся на строке 5 в момент подачи команды? 

35. У многих терминалов, использующих интерфейс К8-232, есть Е8С-после- 
довательности для удаления текущей строки и перемещения всех нижних 
строк на одну строку вверх. Как, по-вашему, реализована эта операция внут¬ 
ри терминала? 

36. На оригинальном компьютере ІВМ РС с цветным дисплеем запись в видео¬ 
память в любое время, кроме того интервала, когда электронный луч совер¬ 
шал вертикальный обратный ход, вызывала появление уродливых пятен 
по всему экрану. На экран выводится 25 строк по 80 символов, каждый из 
которых помещается в квадрат 8x8 пикселов. Каждый ряд из 640 пикселов 
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рисуется за один горизонтальный проход луча, что занимает 63,6 мкс, вклю¬ 
чая горизонтальный обратный ход луча. Экран перерисовывается по 60 раз 
в секунду. При каждом выводе экрана требуется период времени на верти¬ 
кальный обратный ход луча. Какую часть времени видеопамять оказывает¬ 
ся доступной для записи? 

37. Разработчики компьютерной системы предполагали, что максимальная ско¬ 
рость перемещения мыши составит 20 см/с. Если один мики равен 0,1 мм, 
а каждое сообщение мыши занимает три байта, чему будет равна максималь¬ 
ная скорость передачи данных, при условии, что о каждом мики сообщается 
отдельно? 

38. Основными дополнительными цветами являются красный, зеленый и синий. 
Это означает, что любой цвет может быть сконструирован как линейная су¬ 
перпозиция этих цветов. Может ли существовать такая цветная фотография, 
которую невозможно представить при помощи 24-разрядного цвета? 

39. Один из способов вывода символа на растровый экран состоит в копирова¬ 
нии его из таблицы шрифтов процедурой ЪііЫі. Предположим, что некоего 
шрифта используются символы размером 16x24 пиксела в формате КСВ. 

а) Сколько места займет каждый символ в таблице шрифта? 

б) Если копирование одного байта занимает 100 нс, включая накладные рас¬ 
ходы, чему равна скорость вывода в символах в секунду? 

40. Предполагая, что для копирования одного байта требуется 10 нс, сколько 
времени понадобится, чтобы полностью перерисовать отображаемый на ад¬ 
ресное пространство памяти экран, работающий в символьном режиме с раз¬ 
решением 25 строк по 80 символов? Какой результат получится в графичес¬ 
ком режиме с разрешением 1024x768 пикселов при 24 битах на пиксел? 

41. В листинге 5.2 есть обращение к процедуре Ке§ізІегСІазз для регистрации 
объекта ѵатісіазз. В соответствующей программе для X \Ѵіпсіо\ѵз в листин¬ 
ге 5.3 нет ничего похожего на этот вызов. Почему? 

42. В тексте был приведен пример вывода на экран прямоугольника при помо¬ 
щи интерфейса \Ѵіпсіо\ѵз СОІ: 

КесІапд1е(ИсІс. хІеГІ. уГор, хгідИІ;. уЬоиот); 

Действительно ли здесь нужен первый параметр ( Мс ), и если да, то зачем? 
В конце концов, координаты прямоугольника явно задаются остальными па¬ 
раметрами. 

43. 5ЕІМ-терминал используется для отображения \ѵеЬ-страницы, содержащей 
мультфильм с размерами 400x160 пикселов, выводящийся на экран с часто¬ 
той 10 кадров в секунду. Какую часть пропускной способности 100-мегабит- 
ной быстрой сети ЕіЬегпеІ занимает передача по сети мультфильма? 

44. Тест показал хорошую работу 5ЕІМ-терминала с 1-мегабитной сетью. Могут 
ли возникнуть проблемы в многопользовательской ситуации? Подсказка: 
представьте большое количество пользователей, смотрящих запланирован¬ 
ную телевизионную передачу, и то же число пользователей, просматриваю¬ 
щих в браузере сайты Интернета. 
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45. При снижении напряжения питания центрального процессора в п раз во 
столько же раз уменьшается его тактовая частота, а энергопотребление 
снижается в п 2 раз. Предположим, что пользователь печатает один символ 
в секунду, но на обработку введенного символа центральному процессору 
требуется всего 100 мс. Чему будет равно оптимальное значение п и сколь¬ 
ко энергии удастся сэкономить таким образом? Предполагается, что проста¬ 
ивающий центральный процессор вообще не потребляет энергии. 

46. Лэптоп максимально использует режим энергосбережения, включая выклю¬ 
чение дисплея и жесткого диска, когда они не используются в течение неко¬ 
торого времени. Пользователь иногда запускает ІЛЧІХ-программы в тексто¬ 
вом режиме, а временами использует систему X \Уіпс1о\Ѵ5. Пользователь 
замечает, что аккумуляторов хватает намного дольше при использовании 
текстовых программ. Почему? 

47. Напишите программу, имитирующую стабильное запоминающее устрой¬ 
ство. Используйте для моделирования двух дисков два файла фиксирован¬ 
ной длины. 




Глава 6 

Файловые системы 


Всем компьютерным приложениям нужно хранить и получать информацию. Во вре¬ 
мя работы процесс может хранить ограниченное количество данных в собствен¬ 
ном адресном пространстве. Однако емкость такого хранилища ограничена разме¬ 
рами виртуального адресного пространства. Для некоторых приложений такого 
размера вполне достаточно, но для других, например систем резервирования авиа¬ 
билетов, систем банковского или корпоративного учета, одного только виртуаль¬ 
ного адресного пространства будет недостаточно. 

Кроме того, после завершения работы процесса информация, хранящаяся в его 
адресном пространстве, теряется. Для большинства приложений (например, баз 
данных) эта информация должна храниться неделями, месяцами или даже вечно. 
Исчезновение данных после завершения работы процесса для таких приложений 
неприемлемо. Информация должна сохраняться даже при аварийном завершении 
процесса в случае сбоя компьютера. 

Третья проблема состоит в том, что часто возникает необходимость нескольким 
процессам одновременно получить доступ к одним и тем же данным (или части дан¬ 
ных). Если интерактивный телефонный справочник будет храниться в адресном 
пространстве одного процесса, то доступ к нему будет только у этого процесса. Для 
решения этой проблемы необходимо отделить информацию от процесса. 

Таким образом, к долговременным устройствам хранения информации предъяв¬ 
ляются три следующих важных требования: 

1. Устройства должны позволять хранить очень большие объемы данных. 

2. Информация должна сохраняться после прекращения работы процесса, ис¬ 
пользующего ее. 

3. Несколько процессов должны иметь возможность получения одновремен¬ 
ного доступа к информации. 

Обычное решение всех этих проблем состоит в хранении информации на дис¬ 
ках и других внешних хранителях в модулях, называемых файлами. Процессы 
могут по мере надобности читать их и создавать новые файлы. Информация, хра¬ 
нящаяся в файлах, должна обладать устойчивостью (в данном контексте иногда 
применяется термин персистентность), то есть на нее не должны оказывать влия¬ 
ния создание или прекращение работы какого-либо процесса. Файл должен исче¬ 
зать только тогда, когда его владелец дает команду удаления файла. 

Файлами управляет операционная система. Их структура, именование, исполь¬ 
зование, защита, реализация и доступ к ним являются важными пунктами устрой- 
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ства операционной системы. Часть операционной системы, работающая с файла¬ 
ми, называется файловой системой. Ей и посвящена данная глава. 

С точки зрения пользователя наиболее важным аспектом файловой системы 
является ее внешнее представление, то есть именование и защита файлов, опера¬ 
ции с файлами и т. д. Такие детали внутреннего устройства, как использование 
связанных списков или бит-карт для слежения за свободными и занятыми бло¬ 
ками диска, число физических секторов в логическом блоке, представляют для 
пользователя меньший интерес, хотя и крайне важны для разработчиков файло¬ 
вой системы. По этой причине мы разбили главу на несколько разделов. Первые 
два раздела посвящены пользовательскому интерфейсу файлов и каталогов. В сле¬ 
дующих разделах мы рассмотрим способы реализации файловой системы. Нако¬ 
нец, будут приведены несколько примеров существующих файловых систем. 


Файлы 

В следующих нескольких разделах мы рассмотрим файлы с точки зрения пользо¬ 
вателя, то есть обсудим их использование и их свойства. 

Именование файлов 

Файлы относятся к абстрактному механизму. Они предоставляют способ сохра¬ 
нять информацию на диске и считывать ее снова позднее. При этом от пользова¬ 
теля должны скрываться такие детали, как способ и место хранения информации, 
а также детали работы дисков. 

Вероятно, наиболее важной характеристикой любого механизма абстракции 
является то, как именуются управляемые объекты, поэтому мы начнем изучение 
файловой системы с именования файлов. При создании файла процесс дает фай¬ 
лу имя. Когда процесс завершает работу, файл продолжает свое существование 
и по его имени к нему могут получить доступ другие процессы. 

Точные правила именования файлов варьируются от системы к системе, но все 
современные операционные системы поддерживают использование в качестве 
имен файлов 8-символьные текстовые строки. Таким образом, апсігеа, Ъгисе и саіку 
являются допустимыми именами файлов. Часто в именах файлов также разреша¬ 
ется использование цифр и специальных символов, поэтому могут применяться и 
такие имена файлов, как 2, ищепі! и Рщ.2-14. Многие файловые системы поддер¬ 
живают имена файлов длиной до 255 символов. 

В некоторых файловых системах, например ІЖІХ, различаются прописные 
и строчные символы, тогда как в других, таких как МЗ-БОЗ, нет. Таким образом, 
имена файлов тагіа, Магіа и МАША будут означать в системе ІЖІХ три различных 
файла, тогда как в МЗЖОЗ все эти имена будут соответствовать одному файлу. 

Операционные системы \Ѵтс1о\Ѵ5 95 и \Ѵтс1о\Ѵ5 98 используют файловую сис¬ 
тему МЗ-ООЗ и наследуют многие ее свойства, включая именование файлов. Опе¬ 
рационные системы \ѴіпсІо\ѵ5 ЫТ и \Ѵтс1о\ѵ5 2000 также поддерживают файловую 
систему МЗ-БОЗ и наследуют ее свойства. Однако у последних двух операцион¬ 
ных систем имеется своя файловая система (ЫТРЗ), обладающая отличными 
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свойствами (например, именами файлов в кодировке Ііпісосіе). В данной главе при 
упоминании файловой системы \ѴіпсІо\ѵ5 мы будем иметь в виду файловую систе¬ 
му МЗ-БОЗ, являющуюся единственной файловой системой, поддерживаемой все¬ 
ми версиями \Ѵіпс1о\ѵ5. Файловая система ШТ5, используемая в \Ѵіпс1о\Ѵ5 2000, 
будет обсуждаться в главе 11. 

Во многих операционных системах имя файла может состоять из двух частей, 
разделенных точкой, например рго§.с. Часть имени файла после точки называется 
расширением файла и обычно означает тип файла. Так, в МЗ-БОЗ имя файла мо¬ 
жет содержать от 1 до 8 символов плюс расширение от 0 до 3 символов. В системе 
ІЛЧІХ размер расширения файла зависит от пользователя. Кроме того, у файла 
может быть несколько расширений, например рго§.с.2, где .2 обычно использу¬ 
ется, чтобы указать, что файл (рго§.с) был сжат с помощью алгоритма Зива— Лем- 
пеля. Некоторые часто встречающиеся расширения файлов и их значения приве¬ 
дены в табл. 6.1. 

Таблица 6.1 . Некоторые типичные расширения файлов 

Расширение Значение 

ІІІе.Ьак Резервная копия файла 

ІІІе.с Исходный текст программы на С 

ІІІе.діІ Изображение формата СІР 

ЛІе.НІр Файл справки 

(ІІе.ШтІ Документ в формате НТМІ_ (ѵѵеЬ-страница) 

Іііе.ірд Неподвижное изображение стандарта ДРЕСЗ 

(ІІе.трЗ Музыка в формате МРЕСЗ-1 уровень 3 

(ІІе.трд Фильм в формате МРЕСЗ 

ІІІе.о Объектный файл (еще не скомпонованный выходной файл компилятора) 

(ІІе.рФ Документ формата РРР (программы АбоЬе АсгоЬаІ) 

Іііе.рз Документ формата РозіЗсгірІ 

(ІІе.Іех Входной файл для программы форматирования ТЕХ 

ІІІе.ІхІ Текстовый файл общего назначения 

(ІІе.гір Архив, сжатый с помощью алгоритма Зива—Лемпеля 


В некоторых системах (например, в ІЛЧІХ) расширения файлов являются про¬ 
сто соглашениями, и операционная система не принуждает пользователя их строго 
придерживаться. Фшп/ііе.іхі может быть текстовым файлом, но это скорее напо¬ 
минание пользователю, а не руководство к действию для операционной системы. 
С другой стороны, компилятор языка С может отказаться компилировать файлы 
с расширениями, отличными от .с. 

Подобные соглашения особенно полезны, когда одна и та же программа должна 
управлять различными типами файлов. Например, компилятору языка С может 
быть предоставлен список файлов, которые он должен откомпилировать и скомпо¬ 
новать, причем некоторые из этих файлов могут содержать программы на языке С, 
тогда как другие являться ассемблерными файлами. В этом случае именно по рас¬ 
ширениям файлов компилятор сможет отличить одни файлы от других. 
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Система \Ѵіпс1о\ѵз, напротив, знает о расширениях файлов и назначает каждому 
расширению определенное значение. Пользователи (или процессы) могут регист¬ 
рировать расширения в операционной системе, указывая программу, «владеющую» 
данным расширением. При двойном щелчке мыши на имени файла запускается 
программа, назначенная этому расширению, с именем файла в качестве парамет¬ 
ра. Например, двойной щелчок мыши на имени /іІеМос запускает Місгозой \Ѵогс1, 
который открывает файл / ііе.йос . 

Структура файла 

Файлы могут быть структурированы несколькими различными способами. Три 
типа структур показаны на рис. 5.1. Файлнарис. 5.1, а представляет собой неструк¬ 
турированную последовательность байтов. В этом случае операционная система 
не интересуется содержимым файла. Все, что она видит — это байты. Значения 
этим байтам придается программами уровня пользователя. Такой подход исполь¬ 
зуется как в системе ІЛЧІХ, так и в \Ѵіпсіо\ѵз. 


1 Байт 1 Запись 



а б в 

Рис. б. 1 . Три типа файлов: последовательность байтов (а); 
последовательность записей (б); дерево (в) 

Рассмотрение операционной системой файлов как просто последовательнос¬ 
тей байтов обеспечивает максимальную гибкость. Программы пользователя могут 
помещать в файлы все что угодно и именовать их любым удобным для них спосо¬ 
бом. Операционная система не вмешивается в этот процесс, что может быть осо¬ 
бенно ценно для пользователей, собирающихся сделать что-либо необычное. 

Первый шаг по направлению к структуре показан на рис. 6.1, б. В данной моде¬ 
ли файл представляет собой последовательность записей фиксированной длины, 
каждая со своей внутренней структурой. Для файлов, состоящих из записей, важ¬ 
ным является то, что операция чтения возвращает одну запись, а операция записи 
перезаписывает или дополняет одну запись. Несколько десятилетий назад, когда 
вовсю применялись перфокарты, состоящие из 80 колонок отверстий, многие 
операционные системы (на мэйнфреймах) оперировали файлами, состоящими 
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из 80-символьных записей, представляющими собой образы перфокарт. Этими 
операционными системами поддерживались также файлы, состоящие из 132 -сим¬ 
вольных записей, предназначающихся для строковых принтеров (которые в те 
дни печатали по 132 символа в строке). Программы читали из входных файлов 
80-символьные блоки и записывали их в виде 132-символьных блоков, хотя ос¬ 
тальные 52 символа могут быть пробелами. Ни одна современная универсальная 
система не работает подобным образом. 

Третий вариант файловой структуры показан на рис. 6.1, в. При такой организа¬ 
ции файл представляет собой дерево записей, не обязательно одной и той же дли¬ 
ны. Каждая запись в фиксированной позиции содержит поле ключа. Дерево сор¬ 
тировано по ключевому полю, что обеспечивает быстрый поиск заданного ключа. 

Основной файловой операцией здесь является не получение следующей запи¬ 
си, хотя это также возможно, а получение записи с указанным значением ключа. 
Для файла зоопарка, показанного на рис. 6.1, в, можно, например, запросить у сис¬ 
темы запись с ключом пони, не беспокоясь о точном положении этой записи в фай¬ 
ле. При добавлении новых записей операционная система, а не пользователь долж¬ 
на решать, куда ее поместить. Такой тип файлов принципиально отличается от 
неструктурированных потоков байтов, применяемых в ІЖІХ и \Уіпс1о\ѵ5, но они 
широко применяются на больших мэйнфреймах, еще используемых для коммер¬ 
ческой обработки данных. 

Типы файлов 

Многие операционные системы поддерживают различные типы файлов. Напри¬ 
мер, в системах ІЖІХ и \Уіпс1о\ѵ5 проводится различие между регулярными (обыч¬ 
ными) файлами и каталогами. В системе ІЖІХ также различаются символьные 
и блочные специальные файлы. К регулярным файлам относятся все файлы, со¬ 
держащие информацию пользователя. Все файлы на рис. 6.1 являются регулярны¬ 
ми. Каталоги — это системные файлы, обеспечивающие поддержку структуры 
файловой системы. Мы рассмотрим их подробнее ниже. Символьные специаль¬ 
ные файлы имеют отношение к вводу-выводу и используются для моделирова¬ 
ния последовательных устройств ввода-вывода, таких как терминалы, принтеры 
и сети. Блочные специальные файлы используются для моделирования дисков. 
В данной главе мы в первую очередь будем рассматривать регулярные файлы. 

Регулярные файлы в основном являются либо АЗСН-файлами, либо двоичны¬ 
ми файлами. АЗСІІ-файлы состоят из текстовых строк. В некоторых системах каж¬ 
дая строка завершается символом возврата каретки. В других (например, ІЖІХ) 
используется символ перевода строки. В некоторых системах (например, М5-Э05) 
используются оба символа. Строки не обязаны иметь одну и ту же длину. 

Большим преимуществом АЗСІІ-файлов является то, что они могут отобра¬ 
жаться на экране и выводиться на печать так, как есть, без какого-либо преоб¬ 
разования, и могут редактироваться практически любым текстовым редактором. 
Более того, если большое количество программ использует АЗСІІ-файлы для 
входа и выхода, то оказывается несложным соединить вход одной программы с выхо¬ 
дом другой, как это делается в конвейерах оболочки. (Обмен данными между про¬ 
цессами при этом не становится проще, но интерпретация информации облегча¬ 
ется, если для ее выражения применяется стандарт, такой как А5СІІ.) 
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Остальные файлы называются двоичными, то есть они не являются А5СІІ-фай- 
лами. При выводе их на принтер получается невразумительный набор символов, 
напоминающий случайный мусор. Обычно у них есть некая внутренняя структу¬ 
ра, известная программе, использующей их. 

Например, на рис. 6.2, а показан простой исполняемый двоичный файл одной 
из версий системы ІЛЧІХ. Хотя технически файл представляет собой всего лишь 
последовательность байтов, операционная система станет исполнять файл только 
в том случае, если этот файл имеет соответствующий формат. Файл состоит из 
пяти разделов: заголовка, текста, данных, релокационных битов и таблицы симво¬ 
лов. Заголовок начинается с так называемого «магического» числа, идентифи¬ 
цирующего файл как исполняемый (чтобы предотвратить случайное исполнение 
файла другого формата). Следом за «магическим» числом в заголовке располага¬ 
ются размеры различных частей файла, адрес начала исполнения файла и некото¬ 
рые флаговые биты. За заголовком следуют текст программы и данные. Они за¬ 
гружаются в оперативную память и настраиваются на работу по адресу загрузки 
при помощи битов релокации. Таблица символов используется для отладки. 




«Магическое число» 


Размер текста 


Размер данных 


Размер 

5 

** 

релокационного блока 

О 

§ 

Размер таблицы 

го 

СИМВОЛОВ 

со 

Точка входа 


' 


Флаги 


; Текст І 

' 

; Данные І 

' 

; Биты релокации І 


„ Таблица 


СИМВОЛОВ Т 


а 6 

Рис. 6.2. Исполняемый файл (а); архив (б) 
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Второй пример двоичного файла представляет собой файл архива, также из 
системы ШІХ. Он состоит из набора библиотечных процедур (модулей), откомпи¬ 
лированных, но не скомпонованных. Каждой процедуре предшествует заголовок, 
содержащий ее имя, дату создания, владельца, код защиты и размер. Как и в слу¬ 
чае исполняемого файла, заголовки модулей содержат большое количество дво¬ 
ичных чисел. Если скопировать их на принтер, получится полная тарабарщина. 

Все операционные системы должны распознавать по крайней мере один тип 
файлов — свои собственные исполняемые файлы, но некоторые операционные 
системы распознают и другие типы файлов. Старая система ТОР5-20 (для компью¬ 
тера ЭЕСзузІет 20) даже изучала время создания каждого предоставляемого ей 
на исполнение файла. Затем она находила исходный файл и проверяла, не был ли 
он изменен, после того как был создан исполняемый файл. Если оказывалось, что 
исполняемый файл уже устарел, операционная система автоматически переком¬ 
пилировала исходный файл. Если перевести это на язык понятий ІЖІХ, то это 
означало, что программа таке была встроена в оболочку. Расширения файлов были 
обязательными, чтобы операционная система могла определить, какая двоичная 
программа от какого исходного файла произошла. 

Однако такая жесткая заданность типов файлов может оказаться неудобной для 
пользователя, пытающегося сделать что-нибудь, не предусмотренное проекти¬ 
ровщиками операционной системы. Представьте, например, систему, в которой 
файлы программного вывода автоматически получают расширение .сіаі (файлы 
данных). Пусть пользователь написал программу, форматирующую исходные 
тексты программ на С. Эта программа читает файл с расширением .с, обрабатыва¬ 
ет его и затем пишет результат в файл со стандартным расширением .сіаі. Если 
пользователь затем попытается предложить этот файл С-компилятору, операци¬ 
онная система не даст этого сделать, так как у файла для данного действия невер¬ 
ное расширение. Попытка скопировать/ іІе.Лаі в/ ііе.с также будет отвергнута опе¬ 
рационной системой. 

Хотя такая «дружественность» по отношению к пользователю (защищающая 
пользователя от ошибок) может быть полезна для новичков, она ставит опытных 
пользователей в безвыходное положение, заставляя их тратить массу усилий на 
попытки перехитрить операционную систему. 

Доступ к файлам 

В старых операционных системах предоставлялся только один тип доступа к фай¬ 
лам — последовательный доступ. В этих системах процесс мог читать байты или 
записи файла только по порядку от начала к концу. Такой доступ к файлам по¬ 
явился, когда дисков еще не было и компьютеры оснащались магнитофонами. 
Поэтому даже в дисковых операционных системах при последовательном доступе 
к файлу имитировалось его чтение или запись на накопителе на магнитной ленте 
с возможностью многократной перемотки назад. 

С появлением дисков стало возможным читать байты или записи файла в про¬ 
извольном порядке или получать доступ к записям по ключу. Файлы, байты кото¬ 
рых могут быть прочитаны в произвольном порядке, называются файлами произ¬ 
вольного доступа. Такие файлы используются многими приложениями. 
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Файлы произвольного доступа очень важны для многих приложений, напри¬ 
мер для баз данных. Если клиент звонит в авиакомпанию с целью зарезервировать 
место на конкретный рейс, программа резервирования авиабилетов должна иметь 
возможность получить доступ к нужной записи, не читая все тысячи предшеству¬ 
ющих записей, содержащих информацию о других рейсах. 

Для указания места начала чтения используются два метода. В первом случае 
каждая операция геасі задает позицию в файле. При втором способе используется 
специальная операция поиска зеек, устанавливающая текущую позицию. После 
выполнения операции зеек файл может читаться последовательно с текущей по¬ 
зиции. 

В некоторых старых операционных системах, использовавшихся на мэйнфрей¬ 
мах, способ доступа к файлу (последовательный или произвольный) указывался 
в момент создания файла. Это позволяло операционной системе применять раз¬ 
личные методы для хранения файлов разных классов. В современных операцион¬ 
ных системах такого различия не проводится. Все файлы автоматически являют¬ 
ся файлами произвольного доступа. 


Атрибуты файла 

У каждого файла есть имя и данные. Помимо этого все операционные системы свя¬ 
зывают с каждым файлом также и другую информацию, например дату и время 
создания файла, а также его размер. Мы будем называть эти дополнительные све¬ 
дения атрибутами файла. Список атрибутов значительно варьируется от системы 
к системе. В табл. 6.2 показаны некоторые возможные атрибуты, однако суще¬ 
ствуют также и другие возможности. Ни в одной существующей операционной 
системе не присутствуют сразу все приведенные в таблице атрибуты файлов, но 
каждый из них используется в той или иной системе. 


Таблица 6.2. Некоторые возможные атрибуты файлов 


Атрибут 


Значение 


Защита 

Пароль 

Создатель 

Владелец 

Флаг «только чтение» 

Флаг «скрытый» 

Флаг «системный» 

Флаг «архивный» 

Флаг АЗСІІ/двоичный 
Флаг произвольного доступа 
флаг «временный» 

Флаги блокировки 
Длина записи 


Кто и каким образом может получить доступ к файлу 
Пароль для получения доступа к файлу 
Идентификатор пользователя, создавшего файл 
Текущий владелец 

О — для чтения/записи; 1 — только для чтения 
О — нормальный; 1 — не показывать в перечне файлов каталога 
О — нормальный; 1 — системный 
О — заархивирован; 1 — требуется архивация 
О — А5СІІ; 1 — двоичный 

О — только последовательный доступ; 1 — произвольный доступ 
О — нормальный; 1 — для удаления файла по окончании работы 
процесса 

О — неблокированный; отличный от нуля для блокированного 
Количество байтов в записи 


продолжение& 
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Таблица 6.2 ( продолжение ) 

Атрибут 

Значение 

Позиция ключа 

Длина ключа 

Время создания 

Время последнего доступа 
Время последнего изменения 
Текущий размер 
Максимальный размер 

Смещение до ключа в записи 

Количество байтов в поле ключа 

Дата и время создания файла 

Дата и время последнего доступа файла 

Дата и время последнего изменения файла 

Количество байтов в файле 

Количество байтов, до которого можно увеличивать размер файла 


Первые четыре атрибута относятся к защите файла и содержат информацию 
о том, кто может получить доступ к файлу, а кто нет. Возможны различные схемы 
реализации защиты файла, несколько из них мы рассмотрим ниже. В некоторых 
системах пользователь должен для получения доступа к файлу указать пароль. 
В этом случае пароль должен входить в атрибуты файла. 

Флаги представляют собой биты или короткие поля, управляющие некоторы¬ 
ми специфическими свойствами. Например, скрытые файлы не появляются в пе¬ 
речне файлов при распечатке каталога. Флаг архивации представляет собой бит, 
следящий за тем, была ли создана для файла резервная копия. Этот флаг очищает¬ 
ся программой архивирования и устанавливается операционной системой при из¬ 
менении файла. Таким образом программа архивирования может определить, ка¬ 
кие файлы следует архивировать. Флаг «временный» позволяет автоматически 
удалять помеченный так файл по окончании работы создавшего его процесса. 

Атрибуты длина записи, позиция ключа и длина ключа присутствуют только 
у тех файлов, записи которых могут искаться по ключу. Эти атрибуты предостав¬ 
ляют необходимую для поиска ключа информацию. 

Различные атрибуты, хранящие значения времени, позволяют следить за тем, 
когда файл был создан, в последний раз изменен и когда к нему в последний раз 
предоставлялся доступ. Эти сведения можно использовать в различных целях. 
Например, если исходный файл программы был модифицирован после создания 
соответствующего ему объектного файла, то исходный файл должен быть переком¬ 
пилирован. 

Текущий размер файла содержит количество байтов в файле в настоящий мо¬ 
мент. В некоторых старых операционных системах, использовавшихся на мэйн¬ 
фреймах, при создании файла требовалось указать также максимальную длину 
файла, что позволяло операционной системе зарезервировать достаточно места 
для последующего увеличения файла. Современные операционные системы, ра¬ 
ботающие на персональных компьютерах и рабочих станциях, умеют обходиться 
без подобного резервирования. 


Операции с файлами 

Файлы позволяют сохранять информацию и получать ее позднее. В различных 
операционных системах имеются различные наборы файловых операций. Ниже 
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мы перечислим наиболее часто встречающиеся системные вызовы, относящиеся 
к файлам. 

1. СгеаЪе (создание). Файл создается без данных. Этот системный вызов 
объявляет о появлении нового файла и позволяет установить некоторые его 
атрибуты. 

2. Оеі еіе (удаление). Когда файл уже более не нужен, его удаляют, чтобы осво¬ 
бодить пространство на диске. Этот системный вызов присутствует в каж¬ 
дой операционной системе. 

3. Ореп (открытие). Прежде чем использовать файл, процесс должен его от¬ 
крыть. Системный вызов ореп позволяет системе прочитать в оперативную 
память атрибуты файла и список дисковых адресов для быстрого доступа 
к содержимому файла при последующих вызовах. 

4. Сіозе (закрытие). Когда все операции с файлом закончены, атрибуты и 
дисковые адреса более не нужны, поэтому файл следует закрыть, чтобы 
освободить пространство во внутренней таблице. Многие операцион¬ 
ные системы позволяют одновременно открыть ограниченное количество 
файлов. Запись на диск производится поблочно, а закрытие файла вызы¬ 
вает запись последнего блока файла, даже если этот блок еще не заполнен 
до конца. 

5. Кеасі (чтение). Чтение данных из файла. Обычно байты поступают с теку¬ 
щей позиции в файле. Вызывающий процесс должен указать количество 
требуемых данных и предоставить для них буфер. 

6. МгНе (запись). Запись данных в файл, также в текущую позицию в файле. 
Если текущая позиция находится в конце файла, размер файла автомати¬ 
чески увеличивается. В противном случае запись производится поверх су¬ 
ществующих данных, которые теряются навсегда. 

7. Аррепй (добавление). Этот системный вызов представляет собой усечен¬ 
ную форму вызова ѵѵгііе. Он может только добавлять данные к концу фай¬ 
ла. В операционных системах с минимальным набором системных вызовов 
может не быть данного системного вызова. 

8. $еек (поиск). Для файлов произвольного доступа требуется способ указать, 
где располагаются данные в файле. Данный системный вызов устанавлива¬ 
ет файловый указатель в определенную позицию в файле. После выполне¬ 
ния данного системного вызова данные могут читаться или записываться в 
этой позиции. 

9. Сеі; аНхіЬЛез (получение атрибутов). Процессам часто для выполнения их 
работы бывает необходимо получить атрибуты файла. Например, для сбор¬ 
ки программ, состоящих из большого числа отдельных исходных файлов, 
в системе ІІШХ часто используется программа таке. Эта программа иссле¬ 
дует время изменения всех исходных и объектных файлов, благодаря чему 
обходится компиляцией минимального количества файлов. Для выполне¬ 
ния этой работы ей требуется получить атрибуты файлов. 
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10. Беѣ аЫпЬиЬез (установка атрибутов). Некоторые атрибуты файла могут ус¬ 
танавливаться пользователем после создания файла. Этот системный вызов 
предоставляет такую возможность. Например, для файла может быть уста¬ 
новлен код защиты доступа. Большинство других флагов также могут уста¬ 
навливаться при помощи данного системного вызова. 

11. Кепаліе (переименование). Этот системный вызов позволяет изменить имя фай¬ 
ла. Его присутствие в операционной системе не является необходимым, так 
как обычно файл можно скопировать с новым именем, а старый файл удалить. 


Пример программы, использующей 
файловые системные вызовы 

В данном разделе мы рассмотрим простую программу для операционной системы 
ІЖІХ, копирующую один файл в другой. Она приведена в листинге 6.1. Эта про¬ 
грамма обладает минимальной функциональностью и еще худшей способностью 
сообщать об ошибках, но тем не менее она дает достаточное представление о рабо¬ 
те некоторых файловых системных вызовов. 


Листинг 6.1 . Простая программа копирования файла 


/* Программа копирования файлов 
Ііпсіисіе <5у5/1уре5.1і> 

#іпсі ийе <ГспЫ. Ь> 
ііпсіисіе <5Гс11іЬ.Іі> 

Ііпсіисіе <ипі5Ісі.Іі> 
іпр та іп(іпр агдс. сГіаг * агдѵ[]) 
ШеГіпе ВиР_5І2Е 4096 
#ЬеГіпе 01ЛРІЛ_М00Е 0700 
іпЬ таіп(іпТ агдс. сЬаг * агдѵ[]) 
{ 


Контроль и сообщения об ошибках минимальные. */ 

/* включить необходимые файлы заголовков */ 


/* АШ прототип */ 

/* использовать буфер размером 4096 байт 
/* биты защиты для выходного файла */ 


і пр іп_Гс1, оиГ_Гс1, гфсоипт, \Л_соипі: 
сбаг ЬиГГег[ВІІЕ_$І2Е]: 

іГ (агдс != 3) ехіШ): /* если агдс не равен 3, то синтаксическая ошибка */ 

/* Открыть входной файл и создать выходной файл */ 

іп_Гсі = ореп(агдѵ[1]. (НЮСЖѴ); /* открыть входной файл */ 

іГ (іп_Гс1 < 0) ехЩ2); /* если файл не может быть открыт, выход */ 

оиГ_Гсі = сгеар(агдѵ[2]. 01ІТРІІТ_М00Е): /* создать выходной файл */ 

іГ (оиГ_Гсі < 0) ехШЗ): /* если файл не может быть создан, выход */ 

/* Цикл копирования */ 
ѵі/бііе ШУЕ) { 


гфсоипГ = геасІ(іп_Г(1. ЬиГГег, ВІІЕ_5І2Е): 
іГ (гфсоипЬ <= 0) Ьгеак; 

мЬ_соипЬ = мпЬе(оиЬ_Гс1. ЬиГГег, гфсоипЬ); 
ІГ (мЬ соипЬ <= 0) ехіГ(4); 


/* прочитать блок данных */ 

/* если конец файла или ошибка. 

/* выйти из цикла */ 

/* записать данные */ 

/* мЬ соипЬ <= 0 является ошибкой */ 


/* Закрыть оба файла */ 
с1озе(іп_ГсІ): 
с1о5е(оиГ_ГсІ); 

ІГ (гфсоипЬ == 0) /* при последнем чтении ошибки не было */ 

ехіГ(О); 
еізе 

ехЩ5): 


/* ошибка при последнем чтении */ 
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Программа сору/ііе может вызываться, например, при помощи командной строки 
соруГіІе аЬс хуг 

чтобы скопировать файл аЪс в файл лу г. Если файл хуг уже существует, он будет 
перезаписан. В противном случае он будет создан. Программа должна вызываться 
обязательно с двумя аргументами, каждый из которых представляет собой допус¬ 
тимое имя файла. 

Четыре оператора #іпсІи(1е в начале программы обеспечивают включение в про¬ 
грамму большого количества определений и прототипов функций. Это требуется 
для того, чтобы программа удовлетворяла международным стандартам, но не будет 
интересовать нас в дальнейшем. Следующая строка содержит прототип функции 
таіп, что требуется стандартом АКЗІ С, но также не интересует нас в настоящий 
момент. 

Первый оператор #(1е/іпе является макроопределением, определяющим стро¬ 
ку В11Р_ЗІ2Е как макрос, заменяющийся в тексте при компиляции числом 4096. 
Программа будет читать и писать данные кусками по 4096 байт. Создавать подоб¬ 
ные константы и использовать их вместо указания напрямую чисел в программе 
считается хорошим стилем программирования. При этом программа не только ста¬ 
новится более удобочитаемой, но ее также проще и изменять в случае необходи¬ 
мости. Второй оператор #(1е/іпе определяет круг пользователей, способных полу¬ 
чить доступ к выходному файлу. 

Основная программа называется таіп. У нее есть два аргумента, аще и аг@ѵ. 
Этим аргументам присваивается значение операционной системой при вызове 
программы. Первый аргумент сообщает количество параметров (слов) в команд¬ 
ной строке, включая имя программы. Он должен быть равен трем. Второй аргу¬ 
мент представляет собой массив указателей на текстовые строки, содержащие 
параметры командной строки. В данном примере элементы этого массива будут 
содержать указатели на следующие строки: 

агдѵ[0] = "соруНІе'' 
агдѵ[1] = "аЬс" 
агдѵ[2] = "ху 2 " 

Именно из этого массива программа может получить входные параметры. 

В программе объявляются пять переменных. Первые две переменные, 
и оиІ_$й, предназначаются для хранения дескрипторов файлов, представляющих 
собой небольшие целые числа, возвращаемые процедурами открытия или созда¬ 
ния файла. Следующие две переменные, г<1_соипІ и Ш_соипІ, являются байтовы¬ 
ми счетчиками, возвращаемыми, соответственно, процедурами геасі и мгИе. По¬ 
следняя переменная, Ъи//ег , представляет собой символьный массив, используемый 
в качестве буфера для чтения и записи данных. 

Первый исполняемый оператор проверяет равенство счетчика аргументов аще 
трем. Если счетчик аще не равен трем, программа завершается с кодом 1. Любой 
код завершения программы, отличный от 0, означает ошибку. Код завершения про¬ 
граммы является единственным способом сообщения об ошибках, применяемым 
в данной программе. 

Затем программа пытается открыть входной файл и создать выходной файл. 
Если открытие файла проходит успешно, операционная система присваивает 
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переменной іп_/сі положительное значение, соответствующее дескриптору откры¬ 
того файла. При последующих операциях с файлом это число должно указывать 
операционной системе, к какому файлу относится данный системный вызов. 
Соответственно, если удается успешно создать выходной файл, переменной оиі_/сІ 
присваивается значение дескриптора файла, использующегося для его идентифи¬ 
кации. Второй аргумент процедуры сгеаі устанавливает код защиты создаваемого 
файла. Если одна из этих операций завершается неудачей, то вместо дескриптора 
файла возвращается значение - Іи программа выходит с соответствующим кодом 
ошибки. 

Затем начинается цикл копирования с попытки чтения в буфер Ьи//ег 4 Кбайт 
данных. Чтение выполняется при помощи библиотечной процедуры геасі, обраща¬ 
ющейся к системному вызову геасі Первый параметр идентифицирует файл, вто¬ 
рой указывает на буфер, а третий сообщает, сколько байтов следует прочитать. 
Переменной гй_соипі присваивается значение, равное количеству прочитанных 
байтов. В нормальной ситуации это будет 4096 или меньшее число, равное вели¬ 
чине оставшейся части файла. При достижении конца файла переменной п!_соипІ 
будет присвоено число 0. Когда значение переменной Ы_соипІ станет отрицатель¬ 
ным или нулевым, это будет означать, что операцию копирования продолжать более 
невозможно и цикл чтения и записи будет прерван оператором Ъгеак. 

Обращение к библиотечной процедуре гюгііе записывает содержимое буфера 
в выходной файл. Первый параметр указывает файл, второй — буфер, а третий 
содержит количество байтов, которые необходимо записать, подобно библиотеч¬ 
ной процедуре геасі. Обратите внимание, что записывается именно столько бай¬ 
тов, сколько было прочитано, а не весь буфер ВІІР_5І2Е. Этот момент важен, так 
как последняя операция чтения прочитает не 4096 байт, если только длина файла 
не кратна 4 Кбайт. 

Когда весь файл будет прочитан, первое обращение к библиотечной процедуре 
геасі вернет значение 0, которое будет присвоено переменной гсі_соипІ, и цикл пре¬ 
рвется. После этого оба файла закрываются, и программа прекращает свою работу 
с нулевым статусом, соответствующим нормальному завершению. 

Хотя системные вызовы \Ѵіпбо\ѵ5 отличаются от системных вызовов ШПХ, 
общая структура программы копирования файлов, работающей в режиме команд¬ 
ной строки в \Ѵтс1о\ѵ5, схожа с программой, приведенной в листинге 6.1. Мы обсу¬ 
дим системные вызовы \Ѵіпбо\ѵ8 2000 в главе 11. 

Файлы, отображаемые на адресное 
пространство памяти 

Многие программисты считают описанный в предыдущем примере доступ не¬ 
удобным, особенно по сравнению с доступом к обычной памяти. По этой причине 
в некоторых операционных системах, начиная с системы МШ/ПСЗ, был пре¬ 
доставлен способ отображения файлов на адресное пространство работающего 
процесса. Концептуально можно представить себе два новых системного вызова, 
шар и ипшар. Первый системный вызов принимает на входе два параметра: имя фай¬ 
ла и виртуальный адрес памяти, по которому операционная система отображает 
указанный файл. 
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Предположим, например, что некий файл размером 64 Кбайт отображается на 
виртуальную память начиная с адреса 512 К. После этого любая команда процес¬ 
сора, читающая байт по адресу 512 К, получит байт 0 этого файла и т. д. Запись по 
адресу 512 К+21000 изменит байт 21000 файла. Когда процесс завершает свою ра¬ 
боту, модифицированный файл остается на диске, как если бы он был изменен 
системными вызовами зеек и мгііе. 

Для реализации отображения файлов на память изменяются системные внут¬ 
ренние таблицы. При обращении к памяти по адресу от 512 до 576 К происходит 
прерывание из-за отсутствия страницы, обработчик которого предоставляет счи¬ 
танную в память страницу 0 файла. При записи происходит приблизительно тоже 
самое, но страница памяти, на которую отображается страница файла, помечается 
как модифицированная. Если потом эта страница удаляется из памяти алгоритмом 
замены страниц, она записывается в соответствующее место файла. После завер¬ 
шения процесса все модифицированные страницы сохраняются в соответствую¬ 
щих файлах. 

Отображение файлов на память лучше всего работает в операционной системе, 
поддерживающей сегментацию. В такой системе каждый файл может быть ото¬ 
бражен на свой собственный сегмент, так чтобы байт к файла был также байтом к 
сегмента. На рис. 6.3, а показан процесс с двумя сегментами, исполняемым кодом 
программы и данными. Предположим, что процесс копирует файлы подобно про¬ 
грамме из листинга 6.1. Сначала он отображает на сегмент исходный файл, напри¬ 
мер аЬс. Затем он создает пустой сегмент и отображает его на выходной файл, хуг. 
В результате получается ситуация, показанная на рис. 6.3, б. 


Исполняемый 
код программы 


Данные 


Исполняемый 
код программы 


Данные 


аЬс 


хуг 


а 6 

Рис. 6.3. Сегментированный процесс до отображения файлов на адресное пространство (а); 
процесс после отображения существующего файла аЬс на один сегмент и создания нового 

сегмента для файла хуг (б) 

В этот момент процесс может скопировать сегмент-источник в сегмент-прием¬ 
ник с помощью обычного цикла копирования памяти. При этом не требуются сис¬ 
темные вызовы геаб и’мгіѣе. Когда копирование закончено, процесс может выпол¬ 
нить системный вызов ишіар, чтобы удалить эти файлы из адресного пространства, 
и завершить свою работу. Выходной файл ,хуг, теперь будет существовать на дис¬ 
ке, как если бы он был создан обычным путем. 

Хотя отображение на память устраняет необходимость обращения к системным 
вызовам ввода-вывода, вместе с ним появляются новые проблемы. Во-первых, 
в нашем примере операционной системе трудно определить длину выходного 
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файла хуг. Операционная система знает номер максимальной модифицированной 
страницы, но она не может определить, сколько байтов было записано в эту страни¬ 
цу. Предположим, программа использует только страницу 0 и после выполнения 
цикла копирования все байты остались равны 0 (их исходному значению). Возмож¬ 
но, файл хуг состоит из 10 нулей. Может быть, он должен состоять из 100 нулей. 
Кто знает? Операционная система не может этого сказать. Все, что она может сде¬ 
лать — это создать файл, длина которого равна размеру страницы. 

Вторая проблема может возникнуть при попытке одного процесса открыть 
файл, уже отображенный на адресное пространство другого процесса. Если пер¬ 
вый процесс модифицирует страницу, это изменение не отразится на файле до тех 
пор, пока эта страница не будет сохранена в файле. Операционная система долж¬ 
на прилагать особые усилия, чтобы гарантировать, что оба процесса не работают 
с устаревшими версиями файла. 

Третья проблема, связанная с отображением файлов на память, вызвана тем, 
что файл может оказаться больше сегмента памяти и даже больше чем все вирту¬ 
альное адресное пространство. При этом единственный способ работы системного 
вызова тар состоит в отображении на память части файла. Хотя такой метод и рабо¬ 
тает, он все же менее удобен, чем отображение всего файла целиком. 


Каталоги 

В файловых системах файлы обычно организуются в каталоги или папки, кото¬ 
рые, в свою очередь, в большинстве операционных систем также являются файла¬ 
ми. В данном разделе мы рассмотрим каталоги, их организацию, свойства и дей¬ 
ствия, которые могут быть выполнены с ними. 

Одноуровневые каталоговые системы 

Простейшая форма системы каталогов состоит в том, что имеется один каталог, 
в котором содержатся все файлы. Иногда его называют корневым каталогом, но 
поскольку он в таких системах единственный, его название не имеет значение. 
Такая система была весьма распространена на ранних персональных компью¬ 
терах, в частности потому, что у них было всего по одному пользователю. Первый 
в мире суперкомпьютер СБС 6600 1 также имел всего один каталог для всех фай¬ 
лов, несмотря на то, что на нем одновременно работало много пользователей. Это 
решение было принято для сохранения простоты программного обеспечения. 

Схематично однокаталоговая система показана на рис. 6.4. В данном примере 
каталог состоит из четырех файлов. На рисунке буквами А, В и С показаны не име¬ 
на файлов, а их владельцы (так как именно наличие нескольких пользователей 
в такой системе создает проблемы). Преимуществом такой схемы является ее про¬ 
стота и способность быстро находить файлы, так как они могут располагаться толь¬ 
ко в одном месте. 


Разработан Сэймуром Крэйем в корпорации Сопігоі Эаіа Согр. в 1964 году. — Примем, перев. 
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м— Корневой каталог 


Рис. 6.4. Однокаталоговая система, содержащая четыре файла 

Недостаток системы с одним каталогом и несколькими пользователями со¬ 
стоит в том, что различные пользователи могут случайно использовать для сво¬ 
их файлов одинаковые имена. Например, если пользователь А создаст файл 
таіІЬох, а затем пользователь В также создаст файл таіІЬох, то файл, созданный 
пользователем В, запишется поверх файла, созданного пользователем А. Поэтому 
такая схема более не используется в многопользовательских системах, но может 
применяться в небольших встроенных системах, например автомобильной систе¬ 
ме, предназначенной для хранения профилей пользователей для небольшого ко¬ 
личества водителей. 

Двухуровневая система каталогов 

Первым этапом в деле решения проблемы одинаковых имен файлов, создан¬ 
ных различными пользователями, можно считать систему, в которой каждому 
пользователю выделяется один каталог. При этом имена файлов, созданных од¬ 
ним пользователем, не конфликтуют с именами файлов другого пользователя. Схе¬ 
матично такая двухуровневая каталоговая система проиллюстрирована на рис. 6.5. 
Буквы обозначают владельцев каталогов и файлов. Такая организация могла, 
например, использоваться на многопользовательском компьютере или в простой 
сети персональных компьютеров, соединенных с общим файловым сервером 
локальной сетью. 



Рис. 6.5. Двухуровневая каталоговая система 

Когда при такой схеме пользователь пытается открыть файл, система знает, что 
это за пользователь, и ищет файл в соответствующем каталоге. Следовательно, для 
работы в такой системе требуется начальная регистрация пользователя, при кото¬ 
рой пользователь указывает свое имя или идентификатор. В одноуровневой ката¬ 
логовой системе такая процедура не требовалась. 

При реализации такой системы в ее базовой форме пользователи могут полу¬ 
чать доступ только к файлам в своем собственном каталоге. Однако небольшая 
модификация основной схемы позволяет пользователям получать доступ к фай- 
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лам других пользователей. Для этого им нужно указать идентификатор владельца 
файла. Например, команда 

орепС'х") 

может быть вызовом для открытия файлах в каталоге пользователя, а команда 
орепС'папсу/х”) 

может быть вызовом для открытия файлах в каталоге другого пользователя, Нэнси. 

Одна из ситуаций, в которой пользователям может понадобиться получить до¬ 
ступ к файлам, не находящимся в их каталогах, — это выполнение системных дво¬ 
ичных программ. Копирование всех системных программ во все пользовательские 
каталоги крайне неэффективно. Таким образом, возникает необходимость в созда¬ 
нии по крайней мере одного системного каталога, содержащего все исполнимые 
двоичные системные файлы. 

Иерархические каталоговые системы 

Благодаря двухуровневой иерархии исчезают конфликты имен файлов между 
различными пользователями, но ее недостаточно для пользователей с большим 
числом файлов. Обычно пользователям бывает необходимо логически группиро¬ 
вать свои файлы. Например, у профессора может быть набор файлов, образующих 
книгу, которую он пишет для одного курса, другое множество файлов, содержа¬ 
щее программы студентов для иного курса. Третий набор файлов может содержать 
исходные тексты разрабатываемого им нового компилятора, четвертая группа 
файлов — предложения различных грантов, а также электронную почту, расписа¬ 
ние собраний, статьи, игры и т. д. Требуется некий гибкий способ, позволяющий 
объединять эти файлы в группы. 

Следовательно, нужна некая общая иерархия (то есть дерево каталогов). При 
таком подходе каждый пользователь может сам создать себе столько каталогов, 
сколько ему нужно, группируя свои файлы естественным образом. Этот подход 
проиллюстрирован на рис. 6.6. Здесь каталоги А, В я С, содержащиеся в корневом 
каталоге, принадлежат различным пользователям, два из которых создали подка¬ 
талоги для проектов, над которыми они работают. 



Файл пользователя 


Рис. 6.6. Иерархическая каталоговая система 
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Возможность создавать произвольное количество подкаталогов является мощ¬ 
ным структурирующим инструментом, позволяющим пользователям организовать 
свою работу. По этой причине почти все современные файловые системы органи¬ 
зованы подобным образом. 

Имя пути 

При организации файловой системы в виде дерева каталогов требуется некоторый 
способ указания файла. Для этого обычно используются два различных метода. 
В первом случае каждому файлу дается абсолютное имя пути, состоящее из имен 
всех каталогов от корневого до того, в котором содержится файл, и имени самого 
файла. Например, путь /изг/азі/таіІЬох означает, что корневой каталог содержит 
подкаталог и$г, который, в свою очередь, содержит подкаталог азС, где находится 
файл таіІЬох. Абсолютные имена путей всегда начинаются от корневого каталога 
и являются уникальными. В системе ІЖІХ компоненты пути разделяются косой 
чертой /. В ѴѴіпс1о\ѵ.з в качестве разделителя используется обратная косая черта \. 
В системе М1ЛЛ1С8 использовался символ >. Таким образом, одно и то же имя 
пути в этих трех операционных системах будет выглядеть следующим образом: 

ИіпсІсМ) \изг\азІ\таіІЬох 
ІМХ /изг/азі/таі Игах 
МІЛТІС5 >изг>азІ>таі1Ьох 

Если первой буквой имени пути был разделитель, это означало, независимо от 
используемого в качестве разделителя символа, что путь абсолютный. 

Применяется и относительное имя пути. Оно используется вместе с концеп¬ 
цией рабочего каталога (также называемого текущим каталогом). Пользователь 
может назначить один из каталогов текущим рабочим каталогом. В этом случае 
все имена путей, не начинающиеся с символа разделителя, считаются относитель¬ 
ными и отсчитываются относительно текущего каталога. Например, если текущим 
каталогом является /шг/азС, тогда к файлу с абсолютным путем /изг/азІ/таіІЪох 
можно обратиться просто как к таіІЬох. Другими словами, команда ІЛЧІХ 

ср /изг/азі/таіІЬох /изг/азІ/таіІЬох.Ьак 
и команда 
ср таіІЬох таіІЬох. Ьак 

выполнят одно и то же действие, если рабочим каталогом является /жг/азі. Отно¬ 
сительная форма часто оказывается более удобной, но она выполняет то же самое, 
что и абсолютная. 

Некоторым программам бывает нужно получить доступ к файлам независимо 
от того, какой каталог является в данный момент текущим. В этом случае они все¬ 
гда должны использовать абсолютные имена. Например, программе проверки пра¬ 
вописания может понадобиться для выполнения работы прочитать файл /жг/ИЪ/ 
сіісйопагу. В этом случае она должна использовать полное, абсолютное имя файла, 
так как она не знает, каким будет рабочий каталог при ее вызове. Абсолютное имя 
файла будет работать всегда, независимо от того, какой каталог является текущим 
в данный момент. 
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Если программе проверки правописания понадобится большое количество 
файлов из каталога /изг/ИЬ, она может, обратившись к операционной системе, по¬ 
менять рабочий каталог на /изг/ИЬ, после чего использовать просто имя сІісСіопагу 
для первого параметра системного вызова орел. Явно указав свой рабочий каталог, 
программа может использовать в дальнейшем относительные имена, так как точ¬ 
но знает, где она находится в дереве каталогов. 

У каждого процесса есть свой рабочий каталог, поэтому, когда процесс меняет 
свой рабочий каталог и потом завершает работу, это не влияет на работу других 
процессов, и в файловой системе не остается никаких следов от подобных измене¬ 
ний рабочих каталогов. Таким образом, процесс может спокойно менять свой ра¬ 
бочий каталог, когда это ему удобно. С другой стороны, если библиотечная проце¬ 
дура поменяет свой рабочий каталог и не восстановит его при возврате управления, 
программа, вызвавшая ее, может оказаться не в состоянии продолжать свою рабо¬ 
ту, так как ее предположения о текущем каталоге окажутся неверными. По этой 
причине библиотечные процедуры редко меняют свои рабочие каталоги, а когда 
все-таки меняют, то обязательно восстанавливают рабочий каталог перед возвратом. 



Рис. 6.7. Дерево каталогов ІІКІІХ 

Большинство операционных систем, поддерживающих иерархические катало¬ 
ги, имеют специальные элементы в каждом каталоге. Это «.» и «..», означающие 
текущий каталог и родительский каталог. Чтобы продемонстрировать, как это 
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работает, обратимся к дереву каталогов системы ІЖІХ, показанному на рис. 6.7. Для 
некоторого процесса каталог /изг/азі является рабочим. Чтобы переместиться вверх 
по дереву, он может использовать обозначение «..». Например, он может копиро¬ 
вать файл /иаг/ИЪ /сіісііопагу в свой собственный каталог при помощи команды 

ср . ./ІіЬ/сІісГіопагу . 

Две точки являются инструкцией системе подняться вверх (в каталог и$г). По¬ 
сле этого нужно открыть каталог НЪ и найти в нем файл сіісііопагу. 

Одиночная точка означает текущий каталог. Когда команда ср в качестве вто¬ 
рого аргумента получает точку, она интерпретирует ее как текущий каталог и ко¬ 
пирует все файлы туда. Конечно, ту же команду можно было задать и так: 

ср /изг/ІіЬ/йісІіопагу . 

Здесь использование точки позволяет сэкономить время, затрачиваемое пользо¬ 
вателем на набор слова сіісііопагу второй раз. Тем не менее команда 

ср /изг/ІіЬ/сйсІіопагу сіісііопагу 

также прекрасно работает и делает то же самое, что и команда 
ср /изг/ІіЬ/сІісІіопагу /изг/азі/сіісііопагу 

Все эти команды выполняют одни и те же действия. 

Операции с каталогами 

Системные вызовы, управляющие каталогами, значительно менее схожи в различ¬ 
ных системах, чем системные вызовы для работы с файлами. Чтобы дать представ¬ 
ление о том, что они собой представляют и как работают, приведем следующий 
пример (взятый из ІЖІХ). 

1. Сгеаіе. Создать каталог. Только что созданный каталог пуст и не содержит 
других элементов, кроме «.» и «..», автоматически помещаемых в каталог 
операционной системой 1 . 

2. Оеі еіе. Удалить каталог. Может быть удален только пустой каталог. Элемен¬ 
ты «.» и «..» файлами не являются и удалены быть не могут. 

3. Орепсіі г. Открыть каталог. После этой операции каталог может быть прочи¬ 
тан. Например, для распечатки всех файлов, содержащихся в каталоге, про¬ 
грамма, создающая листинг, открывает каталог, чтобы прочитать имена всех 
содержащихся в нем файлов. Прежде чем каталог может быть прочитан, его 
следует открыть, подобно открытию и чтению файла. 

4. С1 озесН г. Закрыть каталог. Когда каталог прочитан, его следует закрыть, что¬ 
бы освободить место во внутренней таблице. 

5. КеасИіг. Прочитать следующий элемент открытого каталога. В прежние вре¬ 
мена было возможно читать каталоги с помощью обычного системного вызо¬ 
ва геаф но такой подход был небезопасен, так как требовал от программиста 

1 Точнее, это не элементы, а обозначения, принятые в командной строке и отображаемые в листингах, 
которым не обязательно соответствуют отдельные элементы каталогов. — Примеч. перев. 
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умения работать с внутренней структурой каталогов. Поэтому был создан от¬ 
дельный системный вызов геасісііг, всегда возвращающий одну запись ката¬ 
лога стандартного формата независимо от используемой структуры каталогов. 

6. Кепаше. Переименование каталога. Во многих отношениях каталоги анало¬ 
гичны файлам и могут переименовываться так же, как и файлы. 

7. Ипк. Связывание представляет собой технику, позволяющую файлу по¬ 
являться сразу в нескольких каталогах. Этот системный вызов принимает 
в качестве входных параметров имя файла и имя пути и создает связь между 
ними. Таким образом, один и тот же файл может появляться сразу в несколь¬ 
ких каталогах. Подобная связь, увеличивающая на единицу счетчик і-узла 
файла (для учета количества каталогов со ссылками на этот файл), иногда 
называется жесткой связью. 

8. Упі і пк. Удаление ссылки на файл из каталога. Если файл присутствует толь¬ 
ко в одном каталоге, то данный системный вызов удалит его из файловой 
системы. Если существует несколько ссылок на этот файл, то будет удалена 
только указанная ссылка, а остальные останутся. Этот системный вызов 
применяется для удаления файла в операционной системе ИМХ. 

Приведенный выше список содержит наиболее важные системные вызовы, но 
существует также множество других, например для управления защитой ин¬ 
формации. 


Реализация файловой системы 

Теперь пора перейти от рассмотрения файловой системы с точки зрения пользо¬ 
вателя к рассмотрению с точки зрения разработчика системы. Пользователей ин¬ 
тересует то, как называются файлы, какие операции возможны с ними, как выгля¬ 
дит дерево каталогов и тому подобные интерфейсные вопросы. Проектировщики 
файловых систем интересуются тем, как хранятся файлы и каталоги, как осуще¬ 
ствляется управление дисковым пространством и как добиться надежной и эффек¬ 
тивной работы файловой системы. В следующих разделах мы познакомимся с этой 
точкой зрения на файловую систему. 

Структура файловой системы 

Файловые системы хранятся на дисках. Большинство дисков делятся на несколь¬ 
ко разделов с независимой файловой системой на каждом разделе. Сектор 0 диска 
называется главной загрузочной записью (МВК, Мазіег Вооі Кесогсі) и исполь¬ 
зуется для загрузки компьютера. В конце главной загрузочной записи содержится 
таблица разделов. В этой таблице хранятся начальные и конечные адреса (номера 
блоков) каждого раздела. Один из разделов помечен в таблице как активный. При 
загрузке компьютера ВІ08 считывает и исполняет МВК-запись, после чего за¬ 
грузчик в МВК-записи определяет активный раздел диска, считывает его первый 
блок, называемый загрузочным, и исполняет его. Программа, находящаяся в за¬ 
грузочном блоке, загружает операционную систему, содержащуюся в этом разделе. 
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Для единообразия каждый дисковый раздел начинается с загрузочного блока, даже 
если в нем не содержится загружаемой операционной системы. К тому же в этом 
разделе может быть в дальнейшем установлена операционная система, поэтому 
зарезервированный загрузочный блок оказывается полезным. 

Во всем остальном строение раздела диска меняется от системы к системе. 
Часто файловые системы содержат некоторые из элементов, показанных на рис. 6.8. 
Один из таких элементов, называемый суперблоком, содержит ключевые пара¬ 
метры файловой системы и считывается в память при загрузке компьютера или 
при первом обращении к файловой системе. Типичная информация, хранящаяся 
в суперблоке, включает «магическое» число, позволяющее различать системные 
файлы, количество блоков в файловой системе, а также другую ключевую адми¬ 
нистративную информацию. 


Весь диск 



Следом располагается информация о свободных блоках файловой системы, напри¬ 
мер в виде битового массива или списка указателей. За этими данными может следо¬ 
вать информация об і-узлах, представляющих собой массив структур данных, по 
одной структуре на файл, содержащих всю информацию о файлах. Следом может раз¬ 
мещаться корневой каталог, содержащий вершину дерева файловой системы. На¬ 
конец, остальное место дискового раздела занимают все остальные каталоги и файлы. 

Реализация файлов 

Вероятно, наиболее важным моментом в реализации храпения файлов является 
учет соответствия блоков диска файлам. Для определения того, какой блок како¬ 
му файлу принадлежит, в различных операционных системах применяются раз¬ 
личные методы. Некоторые из них будут рассмотрены в данном разделе. 

Непрерывные файлы 

Простейшей схемой выделения файлам определенных блоков на диске является 
система, в которой файлы представляют собой непрерывные наборы соседних 
блоков диска. Тогда на диске, состоящем из блоков по 1 Кбайт, файл размером 
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в 50 Кбайт будет занимать 50 последовательных блоков. При 2-килобайтных бло¬ 
ках такой файл займет 25 соседних блоков. 

Пример непрерывных файлов показан на рис. 6.9, а. Здесь показаны первые 
40 блоков диска, начиная с блока 0, слева. Вначале диск был пуст. Затем на диск, 
начиная с блока 0, был записан файл А длиной в четыре блока. После него был 
записан шестиблочный файл В, впритык к файлу А. Обратите внимание, что каж¬ 
дый файл начинается с нового блока, так что если длина файла Л была равна 3!4 
блока, некоторое место в конце последнего блока файла пропадает. На рисунке 
всего показано семь файлов. Каждый следующий файл начинается с блока, следу¬ 
ющего за последним блоком предыдущего файла. Затенение используется только 
для того, чтобы было легче различать отдельные файлы. 

Файл А Файл С Файл Е Файл 3 

(4 блока) (6 блоков) (12 блоков) (3 блока) 


I 1 1 I 1 1.1.} і і і I I 

Файл В 
(3 блока) 



Файл й 
(5 блоков) 

а 


ХЕ 


Файл Р 
(6 блоков) 


(Файл А) (Файл С) (Файл Е) (Файл 3) 



Файл В 5 свободных блоков 6 свободных блоков 


6 

Рис. 6.9. Семь непрерывных файлов на диске (а); состояние 
диска после удаления двух файлов (б) 

У непрерывных файлов есть два существенных преимущества. Во-первых, такую 
систему легко реализовать, так как системе, чтобы определить, какие блоки при¬ 
надлежат тому или иному файлу, нужно следить всего лишь за двумя числами: 
номером первого блока файла и числом блоков в файле. Зная первый блок файла, 
любой другой его блок легко получить при помощи простой операции сложения. 

Во-вторых, при работе с непрерывными файлами производительность просто 
превосходна, так как весь файл может быть прочитан с диска за одну операцию. 
Требуется только одна операция поиска (для первого блока). После этого более 
не нужно искать цилиндры и тратить время на ожидания вращения диска, поэто¬ 
му данные могут считываться с максимальной скоростью, на которую способен 
диск. Таким образом, непрерывные файлы легко реализуются и обладают высо¬ 
кой производительностью. 

К сожалению, у такого способа распределения дискового пространства имеется 
серьезный недостаток: со временем диск становится фрагментированным. Чтобы 
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понять, как это происходит, рассмотрим рис. 6.9, б. Два файла, Ди Р, были удалены. 
Когда файл удаляется, его блоки освобождаются, оставляя промежутки свободных 
блоков на диске. По мере удаления файлов диск становится все более «дырявым». 

Вначале эта фрагментация не представляет проблемы, так как каждый новый 
файл может быть записан в конец диска, вслед за предыдущим файлом. Однако 
в конце концов диск заполнится и либо потребуется специальная операция по уп¬ 
лотнению используемого пространства диска, либо надо будет изыскать способ 
использовать свободное пространство на месте удаленных файлов. Для повторно¬ 
го использования освободившегося пространства потребуется содержать список 
пустых участков, что в принципе выполнимо. Однако при создании нового файла 
будет необходимо знать его окончательный размер, чтобы выбрать для него учас¬ 
ток подходящего размера. 

Представьте себе последствия такой структуры. Пользователь запускает тек¬ 
стовый редактор или текстовой процессор, чтобы создать документ. Первое, что 
интересует программу, это сколько байтов будет в документе. На этот вопрос сле¬ 
дует дать ответ, в противном случае программа не сможет работать. Если пользо¬ 
ватель укажет слишком маленькое число, программа может закончиться аварий¬ 
но, так как свободный участок диска окажется заполнен и будет негде разместить 
остальную часть файла. Если пользователь попытается обойти эту проблему, 
задав заведомо большой окончательный размер, например 100 Мбайт, может 
случиться, что редактор не сможет найти такой большой свободный участок и со¬ 
общит, что не может создать файл. Конечно, пользователь может поторговаться 
и снизить свои требования до 50 Мбайт и т. д. до тех пор, пока не найдется подхо¬ 
дящий свободный участок. Тем не менее такая схема вряд ли доставит удоволь¬ 
ствие пользователям. 

И все-таки есть ситуации, в которых непрерывные файлы могут применять¬ 
ся и в самом деле широко используются: на компакт-дисках. Здесь все размеры 
файлов известны заранее и не могут меняться при последующем использовании 
файловой системы СЭ-КОМ. Наиболее распространенную файловую систему 
СЭ-КОМ мы рассмотрим ниже в этой главе. 

Как уже говорилось в главе 1, в кибернетике история часто повторяется с по¬ 
явлением новых технологий. Файловые системы, состоящие из непрерывных 
файлов, применялись на магнитных дисках много лет назад благодаря их просто¬ 
те и высокой производительности (удобство для пользователей почти не прини¬ 
малось тогда в расчет). Затем эта идея была позабыта из-за необходимости зада¬ 
вать окончательный размер файла при его создании. Но с появлением СЭ-КОМ 
и ОѴТ), а также других одноразовых оптических носителей о преимуществах не¬ 
прерывных файлов вспомнили снова. Изучение старых систем и идей оказыва¬ 
ется полезным, так как многие простые и ясные концепции тех систем находят 
применение в новых системах самым удивительным образом. 

Связные списки 

Второй метод размещения файлов состоит в представлении каждого файла в виде 
связного списка из блоков диска, как показано на рис. 6.10. Первое слово каждого 
блока используется как указатель на следующий блок. В остальной части блока 
хранятся данные. 
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Файл А 



Физический 4 
блок 


7 2 


10 12 


Файл В 


Физический 

блок 



6 3 11 14 


Рис. 6.10. Размещение файла в виде связного списка блоков диска 


В отличие от систем с непрерывными файлами, такой метод позволяет исполь¬ 
зовать каждый блок диска. Нет потерь дискового пространства на фрагментацию 
(кроме потерь в последних блоках файла). Кроме того, в каталоге нужно хранить 
только адрес первого блока файла. Всю остальную информацию можно найти там. 

С другой стороны, хотя последовательный доступ к такому файлу несложен, 
произвольный доступ будет довольно медленным. Чтобы получить доступ к блоку п, 
операционная система должна сначала прочитать первые п - 1 блоков по очереди. 
Очевидно, такая схема оказывается очень медленной. 

Кроме того, размер блока уменьшается на несколько байтов, требуемых для 
хранения указателя. Хотя это и не смертельно, но размер блока, не являющий¬ 
ся степенью двух, будет менее эффективным, так как многие программы читают 
и пишут блоками по 512, 1024, 2048 и т. д. байтов. Если первые несколько байтов 
каждого блока будут заняты указателем на следующий блок, то для чтения блока 
полного размера придется считывать и объединять два соседних блока диска, для 
чего потребуется выполнение дополнительных операций. 

Связный список при помощи таблицы в памяти 

Оба недостатка предыдущей схемы организации файлов в виде связных списков 
могут быть устранены, если указатели на следующие блоки хранить не прямо в 
блоках, а в отдельной таблице, загружаемой в память. На рис. 6.11 показан внешний 
вид такой таблицы для файлов с рис. 6.10. На обоих рисунках показаны два файла. 
Файл А использует блоки диска 4, 7,2,10 и 12, а файл В использует блоки диска 6, 
3,11 и 14. С помощью таблицы, показанной на рис. 6.11, мы можем начать с блока 4 
и следовать по цепочке до конца файла. То же может быть сделано для второго 
файла, если начать с блока 6. Обе цепочки завершаются специальным маркером 
(например -1), не являющимся допустимым номером блока. Такая таблица, загру¬ 
жаемая в оперативную память, называется РАТ-таблицей (Рііе Аііосаііоп ТаЫе — 
таблица размещения файлов). 
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Физический 

блок 


-«— Файл А начинается здесь 


-*— Файл В начинается здесь 


Неиспользуемый блок 
Рис. 6.11. Таблица размещения файлов 

Эта схема позволяет использовать для данных весь блок. Кроме того, случай¬ 
ный доступ при этом становится намного проще. Хотя для получения доступа к 
какому-либо блоку файла все равно понадобится проследовать по цепочке по всем 
ссылкам вплоть до ссылки на требуемый блок, однако в данном случае вся цепоч¬ 
ка ссылок уже хранится в памяти, поэтому для следования по пей не требуются 
дополнительные дисковые операции. Как и в предыдущем случае, в каталоге до¬ 
статочно хранить одно целое число (номер начального блока файла) для обеспе¬ 
чения доступа ко всему файлу. 

Основной недостаток этого метода состоит в том, что вся таблица должна по¬ 
стоянно находиться в памяти. Для 20-гигабайтного диска с блоками размером 
1 Кбайт потребовалась бы таблица из 20 млн записей, по одной для каждого из 
20 млн блоков диска. Каждая запись должна состоять как минимум из трех бай¬ 
тов 1 . Для ускорения поиска размер записей должен быть увеличен до 4 байт. 
Таким образом, таблица будет постоянно занимать 60 или 80 Мбайт оператив¬ 
ной памяти. Таблица, конечно, может быть размещена в виртуальной памяти, но 
и в этом случае ее размер оказывается чрезмерно большим, к тому же постоянная 
выгрузка таблицы на диск и загрузка с диска существенно снизит производитель¬ 
ность файловых операций. 

1-узлы 

Последний метод отслеживания принадлежности блоков диска файлам состоит 
в связывании с каждым файлом структуры данных, называемой і-узлом (іпбех 
и обе — индекс-узел), содержащей атрибуты файла и адреса блоков файла. Простой 

1 Трех байтов будет недостаточно, так как 2 24 = 16 777 216, что чуть меньше 20 млн. — Примеч. перев. 
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пример і-узла показан на рис. 6.12. При наличии і-узла можно найти все блоки 
файла. Большое преимущество такой схемы перед хранящейся в памяти таблицей 
из связных списков заключается в том, что каждый конкретный і-узел должен на¬ 
ходиться в памяти только тогда, когда соответствующий ему файл открыт. Если 
каждый і-узел занимает п байт, а одновременно открыто может быть к файлов, то 
для массива і-узлов потребуется в памяти всего кп байтов. 


Атрибуты файла 


Адрес блока О 
Адрес блока 1 
Адрес блока 2 
Адрес блока 3 
Адрес блока 4 
Адрес блока 5 
Адрес блока 6 
Адрес блока 7 
Адрес блока указателей 






Блок диска, 
содержащий 
дополнительные 
дисковые 
адреса 


Рис. 6.12. Пример і-узла 

Обычно этот размер значительно меньше, чем РАТ-таблица, описанная в пре¬ 
дыдущем разделе. Это легко объясняется. Размер таблицы, хранящей связный 
список всех блоков диска, пропорционален размеру самого диска. Для диска из 
п блоков потребуется п записей в таблице. Таким образом, размер таблицы линей¬ 
но 1 растет с ростом размера диска. Для схемы і-узлов, напротив, требуется массив 
в памяти с размером, пропорциональным максимальному количеству файлов, ко¬ 
торые могут быть открыты одновременно. При этом не важно, будет ли размер 
диска 1 Гбайт, 10 Гбайт или 100 Гбайт. 

С такой схемой связана проблема, заключающаяся в том, что при выделении 
каждому файлу фиксированного количества дисковых адресов этого количества 
может не хватить. Одно из решений заключается в резервировании последнего 
дискового адреса не для блока данных, а для следующего адресного блока, как по¬ 
казано на рис. 6.12. Более того, можно создавать целые цепочки и даже деревья 
адресных блоков. Мы снова вернемся к теме і-узлов, когда приступим к изучению 
системы ИМХ позднее. 


1 Даже быстрее, чем линейно, так как с увеличением числа блоков требуется все большее число битов 
для хранения их номеров. — Примеч. перев. 
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Реализация каталогов 

Прежде чем прочитать файл, его следует открыть. При открытии файла операци¬ 
онная система использует поставляемое пользователем имя пути, чтобы найти за¬ 
пись в каталоге. Запись в каталоге содержит информацию, необходимую для на¬ 
хождения блоков диска. В зависимости от системы это может быть дисковый адрес 
всего файла (для непрерывных файлов), номер первого блока файла (обе схемы 
связных списков) или номер і-узла. Во всех случаях основная функция каталого¬ 
вой системы состоит в преобразовании АЗСП-имени в информацию, необходимую 
для нахождения данных. 

С этой проблемой тесно связан вопрос размещения атрибутов файла. Каждая 
файловая система поддерживает различные атрибуты файла, такие как дату созда¬ 
ния файла, имя владельца файла и т. д„ и всю эту информацию нужно где-то хра¬ 
нить. Один из возможных вариантов состоит в хранении этих сведений прямо 
в каталоговой записи. Многие файловые системы именно так и поступают. Этот 
вариант показан на рис. 6.13, а. В этой простой схеме каталог состоит из списка 
элементов фиксированной длины по одному на файл, содержащих имена файлов, 
структуру атрибутов файла, а также один или несколько дисковых адресов, указы¬ 
вающих расположение файла на диске. 



Структура данных, 
содержащая атрибуты 

Рис. 6.13. Простой каталог, содержащий записи фиксированной длины с атрибутами 
и дисковыми адресами (а); каталог, в котором каждая запись является просто 

ссылкой на і-узел (б) 


Системы, использующие і-узлы, могут хранить атрибуты в і-узлах, а не в за¬ 
писях каталога. В этом случае запись в каталоге может быть короче: просто имя 
файла и номер і-узла. Этот подход показан на рис. 6.13, б. Как мы увидим позднее, 
у этого метода есть определенные преимущества по сравнению с помещением 
атрибутов прямо в каталоговые записи. Два подхода, показанные на рис. 6.13, со¬ 
ответствуют системам М5-Б05 и ІЖІХ, о чем еще будет рассказано в этой главе. 

До сих пор мы предполагали, что файлы имеют короткие имена фиксирован¬ 
ной длины. В системе М5-Б05 файл может иметь имя длиной от 1 до 8 символов, 
а также расширение длиной до 3 символов. В системе ІЖІХ Ѵегзіоп 7 имена фай¬ 
лов могут быть от одного до 14 символов, включая расширение. Однако почти 
всеми современными операционными системами под держиваются более длинные 
имена файлов переменной длины. Как это может быть реализовано? 
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Простейший метод состоит в установке ограничения на длину имени файла, 
обычно 255 символов, и использовании одной из схем, показанных на рис. 6.13. 
Такой способ прост, но он расходует много места в каталоге, так как длинные име¬ 
на обычно бывают далеко не у всех файлов. Следовательно, для более эффек¬ 
тивного использования дискового пространства желательно использовать другую 
структуру. 

Один из альтернативных подходов состоит в отказе от предположения о том, 
что все записи в каталоге должны иметь один и тот же размер. При таком подходе 
каждая запись в каталоге начинается с порции фиксированного размера, обычно 
начинающейся с длины записи, за которой следуют данные в фиксированном фор¬ 
мате — идентификатор владельца, дата создания, информация о защите и прочие 
атрибуты. Следом за заголовком фиксированной длины идет часть записи пере¬ 
менной длины, содержащая имя файла (рис. 6.14, а). На рисунке показаны три 
описателя файла, р і ’о]вс С-Ьи (Іре I , рештпеі и /оо. Имя каждого файла завершается 
специальным символом (обычно 0), обозначенным на рисунке перечеркнутыми 
квадратиками. Чтобы каждая запись в каталоге могла начинаться с границы сло¬ 
ва, имя каждого файла дополняется до целого числа слов байтами, показанными 
на рисунке затененными прямоугольниками. 
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> «Куча» 


Рис. 6.14. Два варианта реализации длинных имен: прямо в записи каталога (а); в «куче» (б) 


Недостаток этого метода состоит в том, что при удалении файла в каталоге ос¬ 
тается промежуток переменной длины, в который описатель следующего файла 
может не поместиться. Эта проблема аналогична проблеме хранения на диске 
непрерывных файлов, хотя уплотнить каталог значительно легче, чем весь диск. 
Другая проблема связана с тем, что каталоговые записи переменной длины могут 
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занимать сразу две страницы памяти. При чтении такой каталоговой записи мо¬ 
жет возникнуть прерывание из-за отсутствия в оперативной памяти следующей 
страницы. 

Другой метод реализации длинных имен файлов заключается в том, чтобы сде¬ 
лать все записи каталога фиксированной (равной) длины и хранить в них только 
указатели на имена, а сами имена хранить отдельно в «куче», в конце каталога, как 
показано на рис. 6.14, б. Преимущество этого метода состоит в том, что при удале¬ 
нии файла освободившееся место в каталоге точно подойдет для нового описате¬ 
ля файла. Тем не менее «кучу» придется все так же «разгребать», и при чтении 
длинного имени из нее также может возникнуть прерывание из-за отсутствия стра¬ 
ницы памяти. Однако имена файлов уже не должны начинаться с границы слов, 
поэтому символы-заполнители не потребуются. 

Во всех рассмотренных нами пока схемах при поиске файла каталоги просмат¬ 
риваются линейно сверху вниз. Для очень больших каталогов, содержащих много 
тысяч файлов, такой поиск может занять довольно много времени. Один из спосо¬ 
бов ускорить поиск файла состоит в использовании хэш-таблицы в каждом ката¬ 
логе. Пусть размер такой таблицы будет равен п. При добавлении в каталог нового 
файла его имя должно хэшироваться в число от 0 до п — \. В качестве хэш-функ¬ 
ции может использоваться, например, взятие остатка от деления имени файла 
на п. В качестве альтернативы можно делить не само имя, а сумму слов, его обра¬ 
зующих. Возможны и другие варианты. 

В любом случае исследуется элемент таблицы, соответствующий полученному 
хэш-коду. Если элемент не используется, туда помещается указатель на описатель 
файла. (Описатели файлов размещаются вслед за хэш-таблицей.) Если же элемент 
таблицы уже занят, то создается связный список, объединяющий все описатели 
файлов с одинаковым хэш-кодом. 

Поиск файла осуществляется аналогично. Имя файла хэшируется. По хэш-коду 
определяется элемент таблицы. Затем проверяются все описатели файла из связ¬ 
ного списка и сравниваются с искомым именем файла обычным способом. Если 
имени файла в связном списке нет, это означает, что файла нет в каталоге. 

Преимуществом использования хэш-таблицы является ускоренный в несколь¬ 
ко раз поиск файла. Недостаток этого метода состоит в более сложном админист¬ 
рировании каталога. Применять этот метод стоит только в тех системах, в кото¬ 
рых ожидается, что каталоги будут содержать сотни и тысячи файлов. 

Принципиально отличный способ ускорения процесса поиска файлов в больших 
каталогах заключается в кэшировании результатов поиска. Прежде чем начать 
поиск файла, проверяется, нет ли его имени в кэше. Если файловая система недавно 
уже искала этот файл, его имя окажется в кэше и повторная операция поиска будет 
выполнена очень быстро. Конечно, кэширование поможет только в том случае, 
если файловая система много раз обращается к небольшому количеству файлов. 


Совместно используемые файлы 

Когда несколько пользователей одновременно работают над одним проектом, им 
часто бывает нужно совместно использовать одни и те же файлы. Поэтому часто 
оказывается удобным, чтобы совместно используемый файл одновременно при- 
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сутствовал в различных каталогах, принадлежащих различным пользователям. 
На рис. 6.15 снова показана файловая система с рис. б.б, только теперь один из 
файлов пользователя С присутствует также в каталоге пользователя В. Соедине¬ 
ние между каталогом пользователя В и совместно используемым файлом называ¬ 
ется связью. Сама файловая система теперь представляет собой ориентирован¬ 
ный ациклический граф (БАС, Эігесіесі Асусііс СгарЬ), а не дерево. 



Совместно 
используемый файл 

Рис. 6.15. Файловая система, содержащая совместно используемый файл 

Совместное использование файлов удобно, но в то же время создает некоторые 
новые проблемы. Если дисковые адреса содержатся в самих каталоговых записях, 
тогда при добавлении новых данных к совместно используемому файлу новые бло¬ 
ки будут числиться только в каталоге того пользователя, который производил эти 
изменения с файлом. Другим пользователям эти изменения будут не видны. 

Эта проблема имеет два решения. Во-первых, информация о блоках диска, за¬ 
нимаемых файлом, может содержаться не в каталоге, а в специальной структуре 
данных, связанной с файлом. В этом случае записи в каталогах будут просто ука¬ 
зывать на эту структуру данных. Этот метод используется в системе ІШІХ (струк¬ 
тура данных называется там і-узлом). 

Второе решение состоит в том, что когда пользователь В устанавливает связь 
с одним из файлов пользователя С, система создает в каталоге пользователя В 
новый файл типа Ы1ЧК (связь). Новый файл содержит просто имя пути к файлу, 
с которым он связан. Когда пользователь В читает данные из связанного файла, 
операционная система видит, что обращение производится к файлу типа ЬШК, по¬ 
этому она открывает файл, с которым связан этот файл, и читает данные из него. 
Такой метод называется символьным связыванием. 

У каждого из этих методов имеются недостатки. В первом методе, когда пользо¬ 
ватель В устанавливает связь с совместно используемым файлом, в і-узле вла¬ 
дельцем файла числится пользователь С. Создание связи не изменяет владельца 
файла (рис. 6.16), а только увеличивает счетчик і-узла, что позволяет системе отсле¬ 
живать количество записей в каталогах, ссылающихся на этот файл. 
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Каталог Каталог Каталог Каталог 

пользователя С пользователя В пользователя С пользователя В 



ООО 


а б в 

Рис. 6.16. Ситуация до связывания (а); после создания связи (б); 
владелец удалил свой файл (а) 

Если впоследствии пользователь С попытается удалить этот файл, операци¬ 
онная система столкнется с проблемой. Если она удалит файл и очистит і-узел, 
у пользователя В окажется запись в каталоге, указывающая на неверный і-узел. 
Если этот і-узел впоследствии будет назначен другому файлу, связь в каталоге 
пользователя В будет ссылаться на неверный файл. По значению счетчика і-узла 
система сможет определить, что этот файл используется кем-то еще, но у нее нет 
способа найти все записи в каталогах, указывающие на этот файл, чтобы удалить 
их. Указатели на каталоги не могут храниться в і-узлах, так как число таких ката¬ 
логов ничем не ограничивается. 

Единственное, что может сделать операционная система — это удалить запись 
в каталоге пользователя С, но оставить на месте і-узел, уменьшив значение счет¬ 
чика на 1, как показано на рис. 6.16, в. Таким образом, мы теперь получили ситуа¬ 
цию, в которой пользователь В является единственным пользователем, имеющим 
ссылку на файл, владельцем которого считается пользователь С. Если система ве¬ 
дет учет или выделяет ограниченные квоты на использование дискового простран¬ 
ства, пользователь С будет продолжать получать счета за этот файл до тех пор, пока 
пользователь В не решит, наконец, удалить его. В этом случае счетчик і-узла умень¬ 
шится до нуля и система удалит файл. 

При символьном связывании такой проблемы не возникает, так как указатель 
на і-узел есть только у владельца файла. У остальных пользователей, установив¬ 
ших связь с этим файлом, есть только пути к файлу, а не указатели на і-узел. Когда 
владелец удаляет файл, файл уничтожается. Последующие попытки использовать 
этот файл при помощи символьной связи не будут иметь успеха, так как система 
не сможет найти файл. Удаление символьной связи никоим образом не повлияет 
на файл. 

Недостатком символьной связи является необходимость накладных расходов. 
Чтобы получить доступ к і-узлу, следует сначала прочитать файл, содержащий 
путь. Затем следует пройти по этому пути, открывая каталог за каталогом, пока, 
наконец, не будет получен нужный і-узел. Все эти действия могут потребовать 
существенного количества обращений к диску. Кроме того, для каждой символь¬ 
ной связи требуется дополнительный і-узел, а также дополнительный блок диска 
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для хранения пути к файлу, хотя, если имя пути короткое, то в качестве оптимиза¬ 
ции система может хранить его в самом і-узле. Преимущество символьных связей 
состоит в том, что они могут использоваться для ссылок на файлы, расположен¬ 
ные на удаленных компьютерах в любой точке земного шара. Для этого, кроме 
обычного пути файла, нужно всего лишь указать сетевой адрес машины, на кото¬ 
рой файл располагается. 

Использование связей, как символьных, так и других, создает еще одну пробле¬ 
му. При использовании связей у одного файла оказывается несколько путей. Про¬ 
граммы, сканирующие каталоги со всеми подкаталогами, могут наткнуться на один 
и тот же файл несколько раз. Если такая программа, например, записывает все 
файлы на магнитофонную ленту, она запишет на ленту несколько копий одного 
и того же файла. Более того, если запись с этой ленты будет потом прочитана на 
другом компьютере, этот файл окажется скопированным на диск несколько раз, если 
только считывающая ленту программа не догадается, что это один и тот же файл. 

Организация дискового пространства 

Обычно файлы хранятся на диске, поэтому организация дискового простран¬ 
ства является основной заботой разработчиков файловой системы. Для хранения 
файла из п байтов возможно использование двух стратегий: выделение на диске 
п последовательных байтов или разбиение файла на несколько непрерывных бло¬ 
ков. Та же дилемма присутствует в системах управления памяти, где имеется вы¬ 
бор между чистой сегментацией и страничной организацией памяти. 

Как уже было показано, при хранении файла в виде непрерывной последова¬ 
тельности байтов возникает проблема, связанная с увеличением его размеров. 
Единственный способ увеличить непрерывный файл состоит в перемещении его 
на новое место на диске. Проблема существенна и для управления сегментами па¬ 
мяти, с той разницей, что перемещение сегмента в памяти является более быстрой 
операцией по сравнению с перемещением файла на диске. По этой причине почти 
все файловые системы хранят файлы в виде блоков фиксированного размера, рас¬ 
положенных в различных частях диска. 

Размер блока 

Как только принято решение хранить файлы блоками фиксированного размера, 
возникает вопрос о размере этих блоков. Учитывая организацию дисков, очевид¬ 
ными кандидатами на роль сегментов файлов являются сектор, дорожка и цилиндр 
диска (минусом такого выбора является зависимость этих параметров от устройств). 
В системе управления страницами памяти размер страницы также входит в число 
основных претендентов. 

Если выбрать большую единицу хранения, такую как цилиндр, это будет озна¬ 
чать, что любой файл, даже состоящий из одного байта, займет как минимум целый 
цилиндр. Изучения показали, что средний размер файла в системе ІШІХ около 
1 Кбайт, так что при выделении каждому файлу 32-килобайтного блока будет рас¬ 
ходоваться понапрасну 31/32 или 97 % общего дискового пространства [241]. 

С другой стороны, при использовании маленьких единиц хранения каждый 
файл будет состоять из большого числа блоков. Для чтения каждого блока файла 
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обычно требуется операция поиска нужного цилиндра и задержка вращения диска, 
поэтому чтение файла, состоящего из большого числа блоков, будет медленным. 

Например, представьте себе диск с 131 072 байтами (128 Кбайт) на дорожку, 
периодом вращения 8,33 мс и средним временем поиска 10 мс. При этом время, 
требующееся для чтения блока из к байтов, будет равно сумме времени поиска, 
задержки вращения и времени переноса данных: 

10 + 4.165 + (к/131072) х 8.33 

Жирная ломаная линия на рис. 6.17 показывает зависимость скорости пере¬ 
дачи данных от размера блока. Чтобы вычислить эффективность использования 
дискового пространства, нам нужно сделать предположение о среднем размере 
файла. Недавние измерения, проведенные автором на факультете, где около 1000 
пользователей компьютеров и более миллиона дисковых файлов системы ІЛЧІХ, 
показали, что медиановый размер файла равен 1680 байт. Это означает, что поло¬ 
вина файлов меньше 1680 байт, а другая половина больше этого размера. Следует 
заметить, что медиановый размер представляет собой лучшую единицу измерения, 
чем средний, так как небольшое количество файлов может очень сильно повлиять 
на среднее значение, но не на медиану. (Среднее значение оказалось равным 
10 845 байт благодаря нескольким 100-мегабайтным руководствам по аппаратуре, 
которые оказались в момент измерений на дисках). Для простоты предположим, 
что все файлы имеют размер, равный 2 Кбайт, в результате чего мы получим штри¬ 
ховую линию, изображающую на рис. 6.17 эффективность использования диско¬ 
вого пространства. 
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Рис. 6.17. Зависимость скорости чтения/записи данных диска (жирная линия, левая шкала) 
и эффективности использования дискового пространства (штриховая линия, правая шкала) 
от размера блоков. Все файлы по 2 Кбайт 


Эти две кривые можно понимать следующим образом. Время доступа к блоку 
практически полностью определяется временем поиска и задержкой вращения, 
поэтому, если считать, что для доступа к блоку требуется 14 мс, чем больше дан¬ 
ных удастся считать за одну такую операцию, тем лучше. Таким образом, скорость 
чтения/записи данных растет пропорционально размеру блока до тех пор, пока 
блок не вырастет настолько, что важнее окажется время передачи блока. При 
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использовании небольших блоков, размер которых составляет степень числа два, 
и 2-килобайтных файлов потерь дискового пространства нет. Однако при хране¬ 
нии 2-килобайтных файлов в 4-килобайтных блоках теряется уже 50 % дискового 
пространства. В действительности мало файлов имеют длину, кратную размеру 
блока, поэтому какая-то часть дискового пространства всегда теряется в последнем 
блоке файла. 

Что показывает данный график? То, что производительность и использование 
дискового пространства являются взаимоисключающими целями. При небольших 
блоках низкая производительность, зато хорошее использование дискового про¬ 
странства, и наоборот. Требуется найти некий компромиссный размер. Для подоб¬ 
ных данных 4 Кбайт может оказаться оптимальным выбором, однако некоторые 
операционные системы сделали свой выбор много лет назад, когда и параметры 
дисков, и размеры файлов были другими. В системе ІЖІХ обычно используется 
размер блока 1 Кбайт. В системе М5-Э05 размер блока может быть любой степе¬ 
нью двух от 512 байт до 32 Кбайт и определяется размером диска (так как макси¬ 
мальное количество блоков в разделе диска равно 2 16 и размер блока оказывается 
пропорциональным размеру диска). 

Пытаясь определить, является ли использование файлов в \Уіпс1о\Ѵ5 ЫТ суще¬ 
ственно отличным от их употребления в ІЖІХ, Фогельс в университете Корнелла 
произвел соответствующие измерения [346]. Он пришел к выводу, что использо¬ 
вание файлов в ЫТ более сложное, чем в ІЖІХ. Он писал: 

Когда мы вводим несколько символов в текстовом редакторе поіерасі, сохраняя 
их в файле, мы запускаем 26 системных вызовов, включая 3 неудачные попытки 
открытия файлов, перезапись одного файла и 4 дополнительных последовательно¬ 
сти операций открытия и закрытия файлов. 

Тем не менее его измерения показали медиановый размер (взвешенный по ис¬ 
пользованию) только читаемых файлов, равный 1 Кбайт, только записываемых 
файлов — 2,3 Кбайт, и файлов, читаемых и записываемых, равный 4,2 Кбайт. Учи¬ 
тывая, что университет Корнелла производил значительно больше масштабных 
научных вычислений, чем учреждение автора, а также различие в технике измере¬ 
ний (статической и динамической), полученные результаты в достаточной мере 
согласуются с медиановым размером файлов около 2 Кбайт. 

Учет свободных блоков 

После того как мы выбрали размер блоков, следует определить, как учитывать 
свободные и занятые блоки. Широкое применение получили два метода, показан¬ 
ные на рис. 6.18. Первый метод представляет собой использование связного спис¬ 
ка блоков диска. При этом в каждом блоке списка содержится столько номеров 
свободных блоков, сколько может поместиться в один блок. При размере блока, 
равном 1 Кбайт, и 32-разрядных номерах блоков каждый блок списка свободных 
блоков может содержать номера 255 свободных блоков. (Одно 32-разрядное сло¬ 
во нужно для указателя на следующий блок списка). Для 16-гигабайтного диска 
потребуется список свободных блоков, состоящий из 16 794 блоков, чтобы со¬ 
держать все 2 24 номера дисковых блоков. Часто для списка резервируется нужное 
число блоков в начале диска. 
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Рис. 6.18. Хранение информации о свободных блоках в виде списка (а); битовый массив (б) 

Другой метод учета свободного дискового пространства состоит в хранении 
этой информации в виде битового массива (иногда называемого бит-картой). При 
этом на каждый блок приходится всего по одному биту вместо 32. Свободные 
блоки обозначаются в массиве единицами, а занятые — нулями (или наоборот). 
16-гигабайтный диск состоит из 2 24 килобайтных блоков, таким образом, для него 
требуется массив размером 2 2і бит, то есть 2048 блоков. 

При использовании метода учета свободных блоков при помощи списка в опе¬ 
ративной памяти требуется хранить только один блок указателей. Когда создает¬ 
ся файл, нужные блоки берутся из блока указателей. Когда указатели в этом блоке 
заканчиваются, читается новый блок с диска. Соответственно, при удалении файла 
его блоки освобождаются, а их номера добавляются в список, хранящийся в опе¬ 
ративной памяти. Когда блок указателей наполняется, он записывается на диск. 

При определенных обстоятельствах такой метод приводит к излишним опера¬ 
циям ввода-вывода. Рассмотрим ситуацию на рис. 6.19, а, в которой в блоке указа¬ 
телей есть место только для еще двух записей (затененные прямоугольники обо¬ 
значают указатели в блоке). При удалении трехблочного файла блок указателей 
переполняется и его нужно записать на диск, что приводит к ситуации, показан¬ 
ной на рис. 6.19, б. Если теперь снова создается трехблочный файл, полный блок 
указателей должен быть снова прочитан с диска, что нас возвращает к ситуации 
на рис. 6.19, а. Если этот трехблочный файл был временным файлом, то он вскоре 
опять удаляется, при этом опять блок указателей пишется на диск. Таким обра¬ 
зом, когда указатели в блоке оказываются на границе блока, возникает необходи¬ 
мость в дополнительных операциях ввода-вывода. 
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Рис. 6.19. Почти полный блок указателей свободных блоков в памяти и три блока указателей 

на диске (а); результат удаления трехблочного файла (б); альтернативная стратегия (в) 

Существует метод, позволяющий избежать лишних операций ввода-вывода. Он 
состоит в том, что полный блок указателей расщепляется на два. При этом из си¬ 
туации иа рис. 6.19, а вместо ситуации на рис. 6.19, б мы переходим к ситуации 
на рис. 6.19, в. При заполнении блока указателей в памяти этот блок записывается 
на диск не в виде заполненного до конца блока, а как блок, заполненный наполови¬ 
ну, то есть записывается, по сути, половина указателей блока. В памяти остается 
блок с остальными указателями, то есть также заполненный наполовину блок. Таким 
образом, хранящийся в оперативной памяти блок указателей максимально готов 
как к добавлению в него новых указателей, так и к освобождению хранящихся в нем. 

При использовании битового массива также возможно хранение в памяти все¬ 
го одного блока с обращением к диску за другим блоком, когда текущий блок пе¬ 
реполняется или, наоборот, становится пустым. Дополнительное преимущество 
такого подхода состоит в том, что выделяемые файлу блоки будут располагаться 
близко друг к другу, в результате чего для доступа к файлу будет затрачено меньше 
времени на перемещение блока головок. Поскольку битовый массив представляет 
собой структуру данных фиксированного размера, то при (частичной) постраничной 
организации ядра битовый массив может быть помещен в виртуальную память, 
откуда можно получать страницы по мере надобности. 

Дисковые квоты 

Чтобы не допустить захвата пользователями слишком больших участков диско¬ 
вого пространства, многопользовательские операционные системы часто содержат 
механизм предоставления дисковых квот. Суть в том, что администратор назнача¬ 
ет каждому пользователю максимальную долю файлов и блоков, а операционная 
система гарантирует, что пользователи не превышают выделенных им квот. Типич¬ 
ный механизм реализации этой идеи описан ниже. 

Когда пользователь открывает файл, операционная система находит его атри¬ 
буты и дисковые адреса и помещает их в таблицу в оперативной памяти. Среди 
атрибутов находится элемент, сообщающий, кто является владельцем данного 
файла. Любые увеличения размеров файла будут учитываться в записи квоты для 
этого пользователя. 

Вторая таблица содержит запись квоты для каждого пользователя, файл кото¬ 
рого открыт в данный момент, даже если этот файл был открыт кем-либо другим. 
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Эта таблица показана на рис. 6.20. Она извлекается из файла квот, хранящегося на 
диске. Когда все файлы закрыты, запись записывается обратно в файл. 


Таблица 

открытых файлов Таблица квот 


Атрибуты 
Дисковые адреса 
Пользователь = 8 


Гибкий лимит блоков 


/ 

Жесткий лимит блоков 


Указатель 

/ 

Текущее количество блоков 


на таблицу квот— 


Количество оставшихся 




предупреждений о блоках 

> 



Гибкий лимит блоков 




Жесткий лимит блоков 




Текущее количество блоков 




Количество оставшихся 
предупреждений о блоках 






Запись квоты для 
пользователя = 8 


Рис. 6.20. Квоты учитываются для каждого пользователя в таблице квот 

Когда в таблице открытых файлов создается новый элемент, в него помещает¬ 
ся указатель на запись квоты владельца файла. При каждом добавлении нового 
блока к файлу общее количество блоков, числящееся за пользователем, увеличи¬ 
вается и сравнивается с гибким и жестким лимитом. Гибкий лимит может быть 
превышен, но жесткий нет. При достижении жесткого лимита любая попытка до¬ 
бавить блок к файлу будет завершаться ошибкой. Аналогично проверяется коли¬ 
чество файлов пользователя. 

Когда пользователь пытается зарегистрироваться в системе, операционная си¬ 
стема считывает его файл квот, проверяя, не превысил ли пользователь гибкие 
пределы по числу блоков или числу файлов. Если один из пределов превышен, 
операционная система выдает предупреждение, а счетчик оставшихся предупреж¬ 
дений уменьшается на единицу. Когда счетчик предупреждений достигает нуля, 
операционная система отказывает пользователю в регистрации. Чтобы снова по¬ 
лучить возможность входить в систему, пользователю необходимо обратиться к 
системному администратору. 

Таким образом, пользователь может превысить свои гибкие лимиты, при усло¬ 
вии, что перед выходом из системы он удалит лишние файлы, превышающие эти 
пределы. Жесткие лимиты превышены быть не могут. 

Надежность файловой системы 

Разрушение файловой системы часто оказывается большим бедствием, чем полом¬ 
ка компьютера. Если компьютер разрушается вследствие пожара, удара молнии 
или пользователь прольет чашку кофе на клавиатуру, это неприятно, ремонт 
потребует денег, но обычно не причинит много хлопот. Недорогие персональные 
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компьютеры можно заменить в течение часа, обратившись к соответствующему 
коммерсанту. (Исключение составляют университеты, в которых для приобрете¬ 
ния персональных компьютеров требуется согласование этого вопроса в трех ко¬ 
митетах, получение пяти подписей и 90 дней ожидания.) 

В случае же потери файловой системы по вине аппаратуры, или программного 
обеспечения, или крыс, прогрызших дополнительные отверстия в гибких дисках, 
восстановление всей информации будет трудным, требующим много времени, а ча¬ 
сто и невозможным делом. Для пользователей, чьи программы, документы, файлы 
клиентов, счета, базы данных, маркетинговые планы или другие данные утеряны 
навсегда, последствия могут оказаться катастрофическими. Хотя операционная 
система не может защитить от физического уничтожения оборудования или но¬ 
сителя, она может помочь сберечь информацию. В данном разделе мы рассмотрим 
некоторые вопросы, касающиеся защиты файловой системы от уничтожения. 

Когда гибкие диски покидают фабрику, их качество, как правило, превосход¬ 
но, но со временем на них могут появиться дефектные блоки. У жестких дисков 
дефектные блоки часто бывают с самого начала, так как производство жестких 
дисков абсолютно без дефектных блоков слишком дорого. Как уже рассказывалось 
в главе 5, дефектные блоки обычно контроллер заменяет специальными запасны¬ 
ми блоками. Тем не менее эта техника не способна защитить абсолютно ото всех 
возможных вариантов потери информации. 

Резервные копии 

Большинство пользователей считает создание резервных копий файлов просто 
потерей времени. Однако когда в один прекрасный день их диск внезапно прика¬ 
зывает долго жить, они диаметрально меняют свои привычки. Компании, напро¬ 
тив, обычно хорошо осознают ценность своей информации и создают резервные 
копии файлов один раз в сутки, чаще всего на магнитной ленте. Современные маг¬ 
нитные ленты вмещают десятки и иногда даже сотни гигабайт при цене в несколь¬ 
ко центов за гигабайт. Тем не менее создание резервных копий является далеко не 
столь тривиальным делом, как это может показаться, поэтому мы ниже рассмот¬ 
рим некоторые аспекты данной темы. 

Резервные копии на магнитной ленте обычно создаются для возможного вос¬ 
становления информации при потенциальном ее уничтожении вследствие аварии 
или ошибки пользователя. К авариям можно отнести такие события, как выход из 
строя жесткого диска, пожары, потопы и другие природные катаклизмы. На прак¬ 
тике такое случается нечасто, поэтому пользователи редко беспокоятся о созда¬ 
нии резервных копий. Как правило, эти пользователи по той же причине не стра¬ 
хуют свое имущество от пожаров и прочих стихийных бедствий. 

Вторая причина состоит в том, что пользователи часто случайно удаляют фай¬ 
лы, которые позднее оказываются нужными. Эта проблема возникает столь часто, 
что в системе \ѴіпсІо\ѵз при обычном удалении файла он на самом деле не удаля¬ 
ется, а помещается в специальный каталог, называемый мусорной корзиной, от¬ 
куда его при необходимости несложно выудить обратно. Резервные копии продол¬ 
жают этот принцип дальше, позволяя восстанавливать с архивных лент файлы, 
удаленные много дней и даже недель назад. 
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Создание резервных копий занимает много времени и требует много места, по¬ 
этому особенное значение при этом получают эффективность и удобство. Во-пер¬ 
вых, следует ли архивировать всю файловую систему или только ее часть? Мно¬ 
гие операционные системы хранят двоичные файлы в отдельных каталогах. Эти 
файлы не обязательно архивировать, так как они могут быть переустановлены 
с СЭ-КОМ производителя. Кроме того, большинство систем имеет каталог для 
временных файлов. В их архивировании также нет необходимости. В системе 
ІЖІХ все специальные файлы (устройств ввода-вывода) хранятся в каталоге /<1еѵ. 
Создавать резервную копию этого каталога не только ненужно, но и опасно, так 
как программа архивации может навсегда повиснуть, если попытается читать эти 
файлы. Поэтому обычно создаются резервные копии отдельных каталогов, а не 
всей файловой системы. 

Во-вторых, архивировать не изменившиеся с момента последней архивации 
файлы неэффективно, поэтому на практике применяется идея инкрементных ре¬ 
зервных копий, или, как их еще называют, инкрементных дампов. Простейшая 
форма инкрементного архивирования состоит в том, что полная резервная копия 
создается, скажем, раз в неделю или раз в месяц, а ежедневно сохраняются только 
те файлы, которые изменились с момента последней полной архивации. Еще 
лучше архивировать только те файлы, которые изменились с момента последней 
архивации. Такая схема сокращает время создания резервных копий, но усложня¬ 
ет процесс восстановления, так как для этого нужно сначала восстановить файлы 
последней полной архивации, а затем проделать ту же процедуру со всеми инкре¬ 
ментными резервными копиями. Чтобы упростить восстановление, часто приме¬ 
няются более сложные схемы инкрементной архивации. 

В-третьих, поскольку объем архивируемых данных обычно очень велик, жела¬ 
тельно сжимать эти данные до записи на магнитную ленту. Однако многие алго¬ 
ритмы сжатия данных устроены так, что малейший дефект ленты может привести 
к нечитаемости всего файла или даже всей ленты. Поэтому следует хорошенько 
подумать, прежде чем принимать решение о сжатии архивируемых данных. 

В-четвертых, создание резервной копии сложно выполнять в активной файло¬ 
вой системе. Если во время архивации создаются, удаляются и изменяются файлы 
и каталоги, то информация в создаваемом архиве может оказаться противоречи¬ 
вой. В то же время, поскольку создание резервной копии может занять несколько 
часов, для этого может понадобиться отключение системы набольшую часть ночи, 
что не всегда приемлемо. По этой причине были разработаны алгоритмы, способ¬ 
ные быстро фиксировать состояние файловой системы для ее архивации, копируя 
критические структуры данных. Последующие изменения файлов и каталогов тре¬ 
бовали вместо их замены дополнительного копирования отдельных блоков [160]. 
Таким образом, файловая система как бы замораживается в момент фиксации и 
может архивироваться позднее. 

Наконец, в-пятых, создание резервных копий создает множество нетехничес¬ 
ких проблем. Лучшая система безопасности, охраняющая информацию, может 
оказаться бесполезной, если системный администратор хранит все свои магнитные 
ленты с резервными копиями в неохраняемом помещении, которое еще и оставля¬ 
ет открытым. Все, что нужно сделать шпиону, это заскочить на секунду в комнату, 
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положить кассету в карман и не спеша покинуть здание. Прощай, безопасность. 
Кроме того, ежедневная архивация принесет мало пользы, если при пожаре погиб¬ 
нут не только компьютеры, но и ленты с резервными копиями. По этой причине 
резервные копии следует хранить в удаленном месте, в результате чего поддержи¬ 
вать безопасность на достаточно высоком уровне становится еще сложнее. Деталь¬ 
ное обсуждение этого и других административных вопросов приводится в [244]. 
Ниже мы обсудим только технические аспекты создания резервных копий файло¬ 
вой системы. 

Для создания резервной копии диска на ленте существует две стратегии: физи¬ 
ческая архивация и логическая архивация. Физическая архивация состоит в по¬ 
блочном копировании на магнитную ленту всего диска с блока 0 по последний 
блок. Эта программа настолько проста, что, возможно, она даже может быть пол¬ 
ностью отлажена, чего нельзя сказать об остальных полезных программах. 

И все же о физической архивации следует сказать несколько слов. Во-первых, 
в копировании неиспользуемых блоков диска мало пользы. Если программа архи¬ 
вации сможет получить доступ к структуре данных, хранящей информацию о сво¬ 
бодных и занятых блоках диска, она может избежать копирования неиспользуе¬ 
мых блоков. Однако тогда придется перед каждым блоком записывать его номер. 

Вторая проблема возникает при столкновении программы архивации с дефект¬ 
ными блоками диска. Если все дефектные блоки контроллер автоматически заме¬ 
няет запасными блоками, как было описано в разделе «Обработка ошибок» гла¬ 
вы 5, тогда физическая архивация работает прекрасно. Однако если дефектные 
блоки видны операционной системе, которая учитывает их в одном или несколь¬ 
ких специальных файлах или битовых массивах, то абсолютно необходимо, чтобы 
программа архивации могла получить доступ к этой информации во избежание 
ошибок чтения диска. 

Главное преимущество физической архивации состоит в ее простоте и высо¬ 
кой скорости (обычно она может работать со скоростью диска). Основными ее не¬ 
достатками являются неспособность пропускать определенные каталоги, произ¬ 
водить инкрементную архивацию и восстанавливать отдельные файлы. По этим 
причинам в большинстве систем применяется логическая архивация. 

Логическая архивация сканирует один или несколько указанных каталогов со 
всеми их подкаталогами и копирует на ленту все содержащиеся в них файлы и ка¬ 
талоги, изменившиеся с указанной даты (например, с момента последней архива¬ 
ции). Таким образом, при логической архивации на магнитную ленту записыва¬ 
ются последовательности детально идентифицированных каталогов и файлов, что 
позволяет восстановить отдельный файл или каталог. 

Поскольку логическая архивация применяется на практике чаще физической, 
познакомимся более детально с алгоритмом архивации на примере, показанном на 
рис. 6.21. Этот алгоритм используется в большинстве систем ИШХ. На рисунке 
показано дерево файлов с каталогами (квадраты) и файлами (кружки). Затенен¬ 
ные элементы были изменены с момента последней архивации и поэтому следует 
создать их резервную копию. Светлые элементы не нуждаются в архивации. Каж¬ 
дый каталог и файл помечены номером своего і-узла. 
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Этот алгоритм также создает резервные копии всех каталогов (даже не моди¬ 
фицированных), расположенных на пути к модифицированному файлу или ка¬ 
талогу. Делается это по двум причинам. Во-первых, чтобы все сохраненные фай¬ 
лы и каталоги можно было восстановить на другом компьютере. Благодаря этому 
программа архивации может использоваться для переноса всей файловой систе¬ 
мы с одного компьютера на другой. 

Во-вторых, сохранение резервных копий всех каталогов, расположенных на 
пути к модифицированному файлу, позволяет восстановить один отдельный файл 
(например, удаленный по ошибке). Представьте, что полная архивация системы 
произведена в воскресенье, а в понедельник выполнена инкрементная архивация. 
Во вторник удаляется каталог /и$г/]кв/рго]/пгЗ со всеми содержащимися в нем 
каталогами и файлами. В среду утром пользователь хочет восстановить файл /изг/ 
]кз/рго]/пгЗ /рІа пв/виттагу. Однако нельзя просто восстановить файл виттагу, так 
как каталоги /ивг/)кв/рго)/пгЗ /ріапв и /ивг/]кв/рго]/пгЗ удалены и файл виттагу 
некуда поместить. Сначала нужно восстановить каталоги пгЗ и ріапв. Чтобы опе¬ 
рационная система смогла корректно установить такие параметры этих каталогов, 
как идентификатор владельца, режимы доступа, время создания, время изменения 
ит.д., эти каталоги должны присутствовать на архивной ленте, несмотря на то, что 
сами каталоги не модифицировались с момента последней архивации. 

Алгоритм архивации создает битовый массив, индексированный по номеру 
і-узла, в котором на каждый і-узел отводится несколько битов. Работа алгоритма 
протекает в четыре этапа. Первый этап начинается в начальном каталоге (напри¬ 
мер, в корневом), в котором исследуются все элементы. Для каждого модифици¬ 
рованного файла его і-узел помечается в битовом массиве. Каждый каталог также 
помечается (независимо от того, был он изменен или нет), после чего он открыва¬ 
ется и рекурсивно исследуется все его содержимое. 
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К концу фазы 1 все модифицированные файлы и все каталоги помечаются в би¬ 
товом массиве, как показано (затенением) на рис. 6.22, а. На втором этапе алгоритм 
снова рекурсивно прошагивает весь каталог, снимая отметку со всех каталогов, в ко¬ 
торых нет модифицированных файлов или каталогов. В результате этих действий 
битовый массив принимает вид, показанный на рис. 6.22, б. Обратите внимание, 
что каталоги 10, 11, 14, 27, 29 и 30 теперь уже не помечены, так как в них и в их 
подкаталогах не содержится ничего модифицированного. Для этих каталогов не 
будет создаваться резервная копия. Напротив, каталоги 5 и 6 будут заархивированы, 
несмотря на то, что сами они не были модифицированы. Однако они потребуются, 
чтобы сегодняшние изменения можно было восстановить на новой машине. Для 
большей эффективности фазы 1 и 2 можно объединить, выполнив их за один проход. 
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Рис. 6.22. Битовые массивы, используемые алгоритмом логической архивации 

К этому моменту алгоритму известно, какие каталоги и файлы должны архи¬ 
вироваться (помеченные на рис. 6.22, б). Фаза 3 состоит из сканирования і-узлов 
по порядку номеров и создания резервных копий всех каталогов, помеченных для 
архивации. Они помечены на рис. 6.22, в. Перед каждым каталогом записываются 
его атрибуты (владелец, времена и т. д.), необходимые для восстановления. Наконец, 
на четвертом этапе файлы, помеченные на рис. 6.22, г, также архивируются со сво¬ 
ими атрибутами, записываемыми перед ними. На этом архивация завершается. 

Восстановление файловой системы происходит достаточно просто. Сначала на 
диске создается пустая файловая система. Затем восстанавливаются данные по¬ 
следней полной архивации. Сначала восстанавливаются каталоги, создавая скелет 
файловой системы, после чего восстанавливаются все файлы. Затем весь процесс 
повторяется со всеми инкрементными архивациями по очереди. 

Хотя алгоритм логической архивации несложен, в этом деле имеется несколь¬ 
ко хитростей. Во-первых, поскольку список свободных блоков не является фай¬ 
лом, он не архивируется, следовательно, его приходится восстанавливать с нуля, 
после того как были восстановлены все архивы 1 . Это всегда является выполнимой 

1 Точнее, никаких специальных действий для коррекции таблицы свободных блоков производить не 
нужно. Восстанавливаемые каталоги и файлы просто создаются заново (тем более что блоки, на ко¬ 
торых они располагались ранее, уже могут оказаться заняты), после чего нужно лишь скорректиро¬ 
вать их атрибуты. — Примеч. перев. 
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задачей, так как множество свободных блоков представляет собой всего лишь со¬ 
вокупность всех блоков, содержащихся во всех файлах. 

Второй проблемой являются связи файлов. Если у файла имеются связи в двух 
или более каталогах, важно, чтобы этот файл был восстановлен только один раз, 
и чтобы во всех каталогах, в которых были ссылки на этот файл, появились имен¬ 
но ссылки. 

Еще одна проблема состоит в том, что в системе ІІШХ файлы могут содержать 
дыры. Считается допустимым открыть файл, записать в него несколько байтов, 
затем переместить указатель в файле на много блоков в глубь файла, после чего 
записать еще несколько байтов. Блоки посередине не являются частью файла и не 
должны архивироваться и восстанавливаться. Файлы, содержащие образы памяти, 
часто содержат большие пустые пространства между сегментом данных и стеком. 
Если их не обрабатывать должным образом, то каждый восстановленный файл с об¬ 
разом памяти заполнит эту область нулями и окажется того же размера, что и вир¬ 
туальное адресное пространство (например, 2 32 байт или, что еще хуже 2 е4 байт). 

Наконец, специальные файлы, называемые каналами или трубами и т. п., никог¬ 
да не должны архивироваться, независимо от того, в котором каталоге они могут 
оказаться (они не обязаны находиться в каталоге /сіеѵ). Дополнительные сведе¬ 
ния о файловой системе см. в [67, 372]. 

Непротиворечивость файловой системы 

Еще одним аспектом, относящимся к проблеме надежности, является непротиво¬ 
речивость файловой системы. Файловые системы обычно читают блоки данных, 
модифицируют их и записывают обратно. Если в системе произойдет сбой преж¬ 
де, чем все модифицированные блоки будут записаны на диск, файловая система 
может оказаться в противоречивом состоянии. Эта проблема становится особен¬ 
но важной в случае, если одним из модифицированных и не сохраненных блоков 
оказывается блок і-узла, каталога или списка свободных блоков. 

Для решения проблемы противоречивости файловой системы на большинстве 
компьютеров имеется специальная обслуживающая программа, проверяющая 
непротиворечивость файловой системы. Например, в системе ІШІХ такой про¬ 
граммой является /зек, а в системе )Уіп<Зо\ѵз это программа зсапсіізк. Эта програм¬ 
ма может быть запущена сразу после загрузки системы, особенно если до этого про¬ 
изошел сбой. Ниже будет описано, как работает утилита /зек. Утилита зсапсіізк 
несколько отличается от /зек, поскольку работает в другой файловой системе, 
однако для нее также остается верным принцип использования избыточной ин¬ 
формации для восстановления файловой системы. Все программы проверки фай¬ 
ловой системы проверяют различные файловые системы (дисковые разделы) не¬ 
зависимо друг от друга. 

Существует два типа проверки непротиворечивости: блоков и файлов. При про¬ 
верке непротиворечивости блоков программа создает две таблицы, каждая из ко¬ 
торых содержит счетчик для каждого блока, изначально установленный на 0. Счет¬ 
чики в первой таблице учитывают, сколько раз каждый блок присутствует в файле. 
Счетчики во второй таблице записывают, сколько раз каждый блок учитывается 
в списке свободных блоков (или в битовом массиве свободных блоков). 
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Затем программа считывает все і-узлы. Начиная с і-узла, можно построить спи¬ 
сок всех номеров блоков, используемых в соответствующем файле. При считыва¬ 
нии каждого номера блока соответствующий ему счетчик увеличивается на едини¬ 
цу. Затем программа анализирует список или битовый массив свободных блоков, 
чтобы обнаружить все неиспользуемые блоки. Каждый раз, встречая номер блока 
в списке свободных блоков, программа увеличивает на единицу соответствующий 
счетчик во второй таблице. 

Если файловая система непротиворечива, то каждый блок будет встречаться 
только один раз, либо в первой, либо во второй таблице, как показано на рис. 6.23, а. 
Однако в результате сбоя эти таблицы могут принять вид, показанный на рис. 6.23, б. 
В этом случае блок два отсутствует в каждой таблице. О таком блоке программа 
сообщит как о недостающем блоке. Хотя пропавшие блоки не причиняют вреда, 
они занимают место на диске, снижая его емкость. Решить проблему пропавших 
блоков очень просто: программа проверки файловой системы просто добавляет эти 
блоки к списку свободных блоков. 
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Рис. 6.23. Состояния файловой системы: непротиворечивое (а); пропавший блок (б); 
дубликат блока в списке свободных блоков (в); дубликат блока данных (г) 




Реализация файловой системы 


469 


Другая возможная ситуация показана на рис. 6.23, в. Здесь мы видим блок но¬ 
мер 4, дважды появляющийся в свободном списке. (Дубликаты свободных блоков 
возможны только в том случае, если файловая система действительно применяет 
списки свободных блоков; при использовании битового массива такая ситуация 
невозможна.) Решение этой проблемы также несложно: построить список свобод¬ 
ных блоков заново. 

Гораздо хуже ситуация, в которой один и тот же блок окажется сразу в двух 
файлах, как показано на рис. 6.23, г в случае с блоком 5. При удалении любого из 
этих файлов блок 5 будет помещен в список свободных блоков, что приведет к си¬ 
туации, в которой один и тот же блок одновременно является и свободным и заня¬ 
тым. Если удалить оба файла, этот блок будет помещен в список свободных бло¬ 
ков дважды. 

В такой ситуации программа проверки файловой системы должна взять сво¬ 
бодный блок, скопировать в него содержимое блока 5 и вставить эту копию в один 
из файлов. Таким образом, содержимое файлов останется неизменным (хотя по¬ 
чти наверняка один из файлов уже испорчен), но, по крайней мере, структура фай¬ 
ловой системы после этой операции становится непротиворечивой. Программа 
также должна выдать сообщение об ошибке, чтобы пользователь мог изучить по¬ 
вреждение. 

Помимо проверки правильности принадлежности блоков программа проверки 
файловой системы также проверяет каталоговую структуру. Для этого также 
используется таблица счетчиков, но уже не для блоков, а для файлов. Проверка 
начинается с корневого каталога с рекурсивным заходом в каждый каталог. Для 
каждого файла в каждом каталоге программа увеличивает на единицу счетчик ис¬ 
пользования файла. Благодаря жестким связям файл может присутствовать сразу 
в нескольких каталогах. Символьные связи не учитываются и не увеличивают 
счетчик. 

Когда сканирование дерева каталогов завершено, программа получает список, 
индексированный по номерам і-узлов, сообщающий, в скольких каталогах присут¬ 
ствует каждый файл. Затем программа сравнивает полученные числа со счетчика¬ 
ми связей, хранящимися в самих і-узлах. Эти счетчики содержат 1 при создании 
файла и увеличиваются на единицу каждый раз, когда создается связь (жесткая) 
с данным файлом. В непротиворечивой файловой системе оба счетчика должны 
совпадать. Однако возможны два типа ошибок: значение счетчика связи в і-узле 
может оказать слишком велико или слишком мало. 

Если счетчик связи больше, чем количество каталоговых записей, тогда даже 
при удалении всех файлов из каталогов счетчик все равно не уменьшится до нуля 
и і-узел не будет удален. Эта ошибка не серьезная, но она приводит к расходованию 
дискового пространства файлом, не находящимся ни в одном каталоге. Чтобы ис¬ 
править ее, следует установить значение счетчика равным числу существующих 
каталоговых записей. 

Вторая ошибка таит в себе катастрофические последствия. Если у файла есть 
две каталоговые записи, связанные с ним, но в і-узле утверждается, что описатель 
у файла только один, тогда при удалении описателя этого файла в любом каталоге 
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счетчик і-узла уменьшится до нуля. При этом файловая система освободит все 
блоки, занимаемые файлом, в том числе и блок, в котором помещается сам і-узел. 
Таким образом, в одном из каталогов сохранится описатель файла, указывающий 
на неиспользуемый і-узел, чьи блоки могут быть вскоре выделены другим файлам. 
Решение также заключается в присваивании значения счетчика і-узла фактичес¬ 
кому числу описателей файла. 

Часто эти две операции, проверки блоков и проверки каталогов, для увеличе¬ 
ния эффективности объединяют в один проход. Возможно также проведение и 
других проверок. Например, формат каталогов должен соответствовать определен¬ 
ным требованиям, с і-узлами и АЗСП-именами. Если і-узел оказывается больше 
числа і-узлов на диске, это означает, что каталог поврежден. 

Более того, у каждого і-узла могут оказаться значения режима доступа, яв¬ 
ляющиеся допустимыми, но странными, как, например, 0007, совсем отказывающий 
в доступе владельцу и его группе, но зато разрешающий всем посторонним пользо¬ 
вателям читать, писать и исполнять файл. Программа должна хотя бы сообщать 
обо всех файлах, предоставляющих посторонним пользователям больше прав, чем 
владельцам. Каталоги, содержащие, скажем, более 1000 описателей файлов, также 
подозрительны. Расположенные в каталогах пользователей файлы, владельцем 
которых является суперпользователь и у которых установлен бит 5ЕТІІШ, пред¬ 
ставляют собой потенциальную проблему безопасности, так как такие файлы при 
запуске любым пользователем приобретают полномочия суперпользователя. Спи¬ 
сок технически возможных, но необычных ситуаций, о которых программа долж¬ 
на сообщать, можно продолжать довольно долго. 

До сих пор мы обсуждали проблему защиты пользователя от сбоев. Некоторые 
файловые системы также пытаются защитить пользователя от самого себя. Если 
пользователь собирается ввести команду 

гга *.о 

чтобы удалить все файлы с расширением .о (созданные компилятором объектные 
файлы), но случайно вместо этого набьет строку 

гга * .о 

(обратите внимание на пробел после звездочки), программа гт удалит все файлы 
в текущем каталоге, после чего сообщит, что не может найти файл .о. В системе 
М5-ООВ и некоторых других системах при удалении файла устанавливается все¬ 
го лишь один бит в каталоге или в і-узле, отмечая, что файл удален. Блоки диска 
не возвращаются 1 в список свободных блоков до тех пор, пока они не понадобятся. 
Таким образом, если пользователь быстро обнаружит ошибку, он сможет восста¬ 
новить удаленные файлы. В системе )Ѵіпбо\ѵз удаленные файлы обычно помеща¬ 
ются в мусорную корзину, откуда их можно при необходимости извлечь. При этом 
свободное пространство на диске не увеличивается до тех пор, пока корзина не 
будет очищена. 


' В М5-Б05 первый символ имени удаленного файла заменяется символом 0хЕ5, а блоки, занимае¬ 
мые файлом, освобождаются. Создаваемый после этого новый файл может занять эти блоки и запись 
в каталоге. Но сразу после удаления файл может быть восстановлен по сохранившемуся (кроме пер¬ 
вого символа имени) описателю в каталоге. — Примем, перев. 
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Производительность файловой системы 

Доступ к диску производится значительно медленнее, чем к оперативной памяти. 
Чтение слова из памяти может занять около 10 нс. Чтение с жесткого диска может 
выполняться со скоростью 10 Мбайт/с, что в сорок раз медленнее, но к этому сле¬ 
дует добавить 5-10 мс на поиск нужного цилиндра и задержку вращения диска. 
Если требуется прочитать или записать всего одно слово, то оперативная память 
оказывается примерно в миллион раз быстрее жесткого диска. Поэтому во многих 
файловых системах применяются различные методы оптимизации, увеличиваю¬ 
щие производительность. В данном разделе мы рассмотрим три из них. 

Кэширование 

Для минимизации количества обращений к диску применяется блочный кэш или 
буферный кэш. (Термин «кэш» происходит от французского слова саскег, что зна¬ 
чит «скрывать»), В данном контексте кэшем называется набор блоков, логически 
принадлежащих диску, но хранящихся в оперативной памяти по соображениям 
производительности. 

Существуют различные алгоритмы управления кэшем. Обычная практика за¬ 
ключается в перехвате всех запросов чтения к диску и проверке наличия требую¬ 
щихся блоков в кэше. Если блок присутствует в кэше, то запрос чтения блока мо¬ 
жет быть удовлетворен без обращения к диску. В противном случае блок сначала 
считывается с диска в кэш, а оттуда копируется по нужному адресу памяти. По¬ 
следующие обращения к тому же блоку могут удовлетворяться из кэша. 

Работа кэша показана на рис. 6.24. Поскольку в кэше хранится большое количе¬ 
ство (часто тысячи) блоков, требуется некий быстрый способ определения наличия 
или отсутствия блока в кэше. Обычно для этого используется хэширование номе¬ 
ра устройства и дискового адреса (номера блока) и поиск результата в хэш-табли¬ 
це. Все блоки с одинаковыми хэш-кодами сцепляются вместе в связный список. 



Когда требуется загрузить блок в заполненный до предела кэш, какой-либо 
другой блок должен быть удален из кэша (и записан на диск, если он был модифи¬ 
цирован в кэше). Эта ситуация очень похожа на страничную организацию памяти, 
и к ней применимы все обычные алгоритмы замены, описанные в главе 3, такие 
как РІРО (РІГ5І іп Рігзі Оиі — первым прибыл — первым обслужен), «вторая по¬ 
пытка» и ЫШ (Ьеаз! КесепПу Шесі — с наиболее давним использованием). Одно 
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приятное отличие кэширования от страничной организации памяти состоит в том, 
что обращения к кэшу производятся относительно нечасто, что позволяет хранить 
все блоки в точном ЫШ-порядке со связными списками. 

На рис. 2.24 мы видим, что в дополнение к цепям, начинающимся в хэш-табли¬ 
це, используется также и двунаправленный список, в котором содержатся номера 
всех блоков в порядке их использования. При этом самый старый блок помещает¬ 
ся в начало списка, а самый новый блок — в его конец. При обращении к блоку 
блок может перемещаться со своей текущей позиции в конец двунаправленного 
списка. Таким образом, может поддерживаться точный ЫШ-порядок. 

К сожалению, здесь есть одна загвоздка. Теперь, когда мы можем реализовать 
точное выполнение алгоритма ЫШ, оказывается, что алгоритм ЫШ является не¬ 
желательным. Вызвано это тем, что буквальное применение алгоритма ЫШ сни¬ 
жает надежность файловой системы и угрожает ее непротиворечивости (обсуж¬ 
давшейся в предыдущем разделе). Если в кэш считывается и модифицируется 
критический блок, например блок і-узла, но не записывается тут же на диск, то 
компьютерный сбой может привести к тому, что файловая система окажется в про¬ 
тиворечивом состоянии. Если блок і-узла поместить в конец цепочки ЫШ, то мо¬ 
жет пройти довольно много времени, прежде чем этот блок попадет в ее начало 
и будет записан на диск. 

Более того, к некоторым блокам, таким как блоки і-узлов, программы редко 
обращаются дважды в течение короткого интервала времени. Исходя из этих со¬ 
ображений, мы приходим к модифицированной схеме ЫШ, принимая во внима¬ 
ние два следующих фактора: 

1. Насколько велика вероятность того, что данный блок скоро снова пона¬ 
добится? 

2. Важен ли данный блок для непротиворечивости файловой системы? 

Для ответа на каждый из этих вопросов блоки можно разделить на такие кате¬ 
гории, как блоки і-узлов, косвенные блоки, блоки каталогов, блоки, полные дан¬ 
ных, и блоки, частично заполненные данными. Блоки, которые, вероятно, не по¬ 
требуются снова в ближайшее время, помещаются в начало списка ЫШ, чтобы 
занимаемые ими буферы могли вскоре освободиться. Блоки, вероятность повтор¬ 
ного использования которых в ближайшее время высока (например, записывае¬ 
мые блоки, частично заполненные данными), помещаются в конец списка ЫШ, 
что позволяет им оставаться в кэше более долгое время. 

Второй вопрос не связан с первым. Если блок представляет важность для не¬ 
противоречивости файловой системы (обычно это все блоки, кроме блоков дан¬ 
ных) и такой блок модифицируется, то его следует немедленно сохранить на дис¬ 
ке независимо от его положения в списке ЫШ. Быстро записывая критические 
блоки, мы значительно снижаем вероятность того, что сбой компьютера повредит 
файловую систему. Пользователь вряд ли будет рад потере одного из своих фай¬ 
лов из-за сбоя компьютера. Еще более он огорчится, если при этом испорченной 
окажется вся файловая система. 

Даже при принятии всех перечисленных выше мер предосторожности по 
поддержанию в рабочем состоянии файловой системы слишком долгое хранение 
в кэше блоков с данными является нежелательным. Представьте себе пользовате- 
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ля, работающего на персональном компьютере над написанием книги. Даже если 
наш писатель периодически велит текстовому редактору сохранять редактируе¬ 
мый файл на диске, есть большая вероятность, что все блоки останутся в кэше. 
Если произойдет сбой, структура файловой системы не пострадает, но работа 
целого дня работы будет потеряна. 

Эта ситуация случается не слишком часто, если только с очень невезучими 
пользователями. Для решения данной проблемы обычно применяется два метода. 
В системе ІШІХ есть системный вызов зупс, принуждающий сохранение всех мо¬ 
дифицированных блоков кэша на диске. При загрузке операционной системы за¬ 
пускается фоновая задача, обычно называющаяся ирсіаіе, вся работа которой за¬ 
ключается в периодическом (обычно через каждые 30 с) обращении к системному 
вызову зупс. В результате при любом сбое будет потеряно не более 30 с работы. 

В системе М5-Э05 используется другой подход, состоящий в том, что каждый 
модифицированный блок записывается на диск сразу же. Кэш, в котором все мо¬ 
дифицированные блоки немедленно записываются на диск, называются сквозным 
кэшем или кэшем со сквозной записью. При использовании сквозного кэша ко¬ 
личество обращений ввода-вывода к диску больше, чем при применении обычного 
кэша. Чтобы лучше понять разницу в этих двух подходах, представьте себе програм¬ 
му, записывающую блок размером в 1 Кбайт по одному символу. Система ІЛЧІХ 
будет собирать все символы в кэше и записывать этот блок на диск каждые 30 с 
или когда блок будет удален из кэша. Система М5-Э05 будет обращаться к диску 
при каждом записываемом символе. Конечно, большинством программ применя¬ 
ется внутренняя буферизация, поэтому обычно они обращаются к системному 
вызову мгПе не с одним символом, а с целыми строками или большими единица¬ 
ми данных. 

Результатом различия стратегий кэширования оказывается тот факт, что про¬ 
стое удаление (гибкого) диска из системы ІЛЧІХ, без выполнения системного вы¬ 
зова зупс, почти всегда приведет к потере данных и часто также к повреждению 
файловой системы. В М5-Э05 такой проблемы не возникает. Такое различие в стра¬ 
тегиях связано с тем, что система ІЛЧІХ разрабатывалась в среде, в которой все 
диски были жесткими и постоянными, тогда как система М5-Э05 изначально 
предназначалась для работы с гибкими дисками. Когда жесткие диски стали нор¬ 
мой, более эффективный метод, применяющийся в ІЖІХ, стал нормой и теперь 
также используется в Шішіоѵѵз для жестких дисков. 

Опережающее чтение блока 

Второй метод увеличения производительности файловой системы состоит в по¬ 
пытке получить блоки диска в кэш прежде, чем они потребуются. В частности, 
многие файлы считываются последовательно. Когда файловая система получает 
запрос на чтение блока к файла, она выполняет его, но после этого сразу проверя¬ 
ет, есть ли в кэше блок к+ 1. Если этого блока в кэше нет, файловая система читает 
его в надежде, что к тому моменту, когда он понадобится, этот блок уже будет счи¬ 
тан в кэш. В крайнем случае, он уже будет на пути туда. 

Конечно, такая стратегия работает только для тех файлов, которые считываются 
последовательно. Если обращения к блокам файла производятся в случайном по¬ 
рядке, опережающее чтение не помогает. В самом деле, не хотелось бы обременять 
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диск считыванием ненужных блоков и удалением потенциально полезных блоков 
из кэша (возможно, тем самым еще более обременяя диск необходимостью записы¬ 
вать эти блоки на диск, если они модифицированы). Чтобы определить, следует 
ли использовать опережающее чтение блоков, файловая система может вести учет 
доступа к блокам каждого открытого файла. Например, для каждого открытого 
файла один бит может означать «режим последовательного доступа» или «режим 
произвольного доступа». Вначале каждому открываемому файлу в соответствии 
с принципом презумпции невиновности назначается режим последовательного до¬ 
ступа. Однако при перемещении указателя в файле этот бит сбрасывается. Если к 
этому файлу опять будут обращаться с запросами последовательного чтения, бит 
будет установлен снова. Таким образом, файловая система может строить догадки 
о том, следует ли ей выполнять операции опережающего чтения или нет. Если она 
и будет ошибаться время от времени, то ничего страшного не произойдет, просто 
будет потрачен впустую некоторый процент пропускной способности диска. 

Снижение времени перемещения блока головок 

Кэширование и опережающее чтение являются не единственными способами уве¬ 
личения производительности системы. Другой важный метод состоит в уменьше¬ 
нии затрат времени на перемещение блока головок. Достигается это помещением 
блоков, к которым высока вероятность доступа в течение короткого интервала вре¬ 
мени, близко друг к другу, желательно на одном цилиндре. Когда записывается 
выходной файл, файловая система должна зарезервировать место для чтения та¬ 
ких блоков за одну операцию. Если свободные блоки учитываются в битовом мас¬ 
сиве, а весь битовый массив помещается в оперативной памяти, то довольно легко 
выбрать свободный блок как можно ближе к предыдущему блоку. В случае когда 
свободные блоки хранятся в списке, часть которого в оперативной памяти, а часть 
на диске, сделать это значительно труднее. 

Однако даже при использовании списка свободных блоков может быть выпол¬ 
нена определенная кластеризация блоков. Хитрость заключается в том, чтобы учи¬ 
тывать место на диске не в блоках, а в группах последовательных блоков. Если сек¬ 
тор состоит из 512 байт, система может использовать блоки размером в 1 Кбайт 
(2 сектора), но выделять пространство на диске в единицах по 2 блока (4 сектора). 
Это не то же самое, что использование 2-килобайтных дисковых блоков, так как 
кэш по-прежнему будет использовать килобайтные блоки и дисковые операции 
чтения и записи будут по-прежнему работать с килобайтными блоками. Одна¬ 
ко при последовательном чтении файла количество операций поиска цилиндра 
уменьшится вдвое, что значительно увеличит производительность. Вариация этой 
же темы состоит в попытке системы учесть позицию блока в цилиндре. 

Еще один фактор, снижающий производительность файловых систем, связан 
с тем, что при использовании і-узлов или чего-либо эквивалентного им, особенно 
при чтении коротких файлов, требуется два обращения к диску вместо одного: 
одно для і-узла и одно для блока данных. Обычное размещение і-узлов на диске 
показано на рис. 6.25, а. Здесь все і-узлы располагаются в начале диска, так что 
среднее расстояние между і-узлом и его блоками будет составлять около полови¬ 
ны количества цилиндров, то есть при доступе практически к каждому файлу по¬ 
требуются значительные перемещения блока головок. 
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і-узлы располагаются 



а 


Диск разделен на группы 
цилиндров, каждая со своими 
собственными блоками и і-узлами 



Рис. 6.25.1-узлы, размещенные в начале диска (а); диск, разделенный на группы цилиндров, 
каждая со своими собственными блоками и і-узлами (б) 


Один из способов увеличения производительности состоит в помещении і-узлов 
в середину диска, уменьшая, таким образом, среднее расстояние перемещения бло¬ 
ков головок в два раза. Другая идея, показанная на рис. 2.25, 6 , заключается в раз¬ 
биении диска на группы цилиндров, каждая со своими і-узлами, блоками и спис¬ 
ком свободных блоков [230]. Когда создается новый файл, может быть выбран 
любой і-узел, но предпринимается попытка найти блок в той же группе цилинд¬ 
ров, что и і-узел. Если эта попытка заканчивается неудачей, используется блок 
в соседней группе цилиндров. 


Файловые системы с журнальной структурой 1_Р$ 

Изменения в технологии оказывают влияние на современные файловые системы. 
В частности, центральные процессоры становятся все быстрее, емкость дисков 
увеличивается, цена их снижается (но скорость их увеличивается не столь значи¬ 
тельно), а размеры оперативной памяти растут экспоненциально. Единственным 
параметром, не растущим столь стремительно, является время поиска цилиндра 
диска. В результате во многих файловых системах появляется узкое место. В уни¬ 
верситете Беркли были проведены исследования, направленные на снижение ост¬ 
роты этой проблемы при помощи создания совершенно новой файловой системы 
БЕЗ (Ьо§-зі:гисі:игесІ Рііе ЗузЬет — файловая система с журнальной структурой). 
В этом разделе мы кратко опишем, как работает система БЕЗ. Дополнительные 
сведения можно узнать в [280]. 

В основе системы БЕЗ лежит идея того, что по мере ускорения центральных 
процессоров и увеличения размеров оперативной памяти кэширование дисков 
становится все выгоднее. Поэтому становится возможным удовлетворить весьма 
существенную часть всех дисковых запросов прямо из кэша файловой системы 
без обращения к диску. Из этого следует, что в будущем большинство обращений 
к диску будут составлять обращения записи, поэтому алгоритм опережающего 
чтения, применявшийся в некоторых файловых системах, уже не дает большого 
выигрыша производительности. 
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Ситуация усложняется тем, что в большинстве файловых систем операции за¬ 
писи выполняются очень маленькими блоками данных. Такие операции записи 
оказываются крайне неэффективными, поскольку самой записи, занимающей 
50 мкс, часто предшествует поиск цилиндра в течение 10 мс и 4-миллисекундная 
задержка вращения. При таких параметрах эффективность диска падает до 1 %. 

Чтобы понять, из чего складываются все эти мелкие операции записи, рассмот¬ 
рим создание файла в операционной системе ЕШІХ. Для записи в файл необходи¬ 
мо произвести операции записи в і-узел каталога, блок каталога, і-узел файла 
и, наконец, блок самого файла. В принципе эти операции записи могут быть от¬ 
ложены на некоторое время, но при этом могут возникнуть серьезные проблемы 
с непротиворечивостью файловой системы в случае сбоя компьютера прежде, чем 
будет выполнена запись на диск. По этой причине і-узлы обычно записываются 
на диск без промедления. 

Учитывая все вышесказанное, разработчики файловой системы ЬЕ5 решили 
реализовать файловую систему ІШІХ таким образом, чтобы достичь максимума 
эффективности использования диска, несмотря на рабочую нагрузку, состоящую 
из большого количества случайных мелких операций записи. Замысел состоит 
в использовании диска как журнала. Периодически, когда возникает необходи¬ 
мость, все буферизированные в памяти блоки, которые должны быть записаны, со¬ 
бираются вместе в единый сегмент, и он записывается на диск одним непрерыв¬ 
ным куском в конец журнала. Записываемый сегмент может содержать і-узлы, 
блоки каталогов и блоки данных, перемешанные друг с другом. В начале каждого 
сегмента создается оглавление сегмента. Если довести средний размер сегмента до 
1 Мбайт, то можно использовать почти всю пропускную способность диска. 

При такой организации і-узлы существуют и имеют ту же структуру, что и в ІШІХ, 
но теперь они, вместо того чтобы располагаться в фиксированной позиции на дис¬ 
ке, перемешаны по всему журналу. Тем не менее, когда программа находит і-узел, 
определение расположения блоков выполняется обычным способом. Конечно, те¬ 
перь обнаружить і-узел намного сложнее, так как его адрес не определяется по его 
номеру, как это было в ІШІХ. Чтобы можно было найти і-узел, создается массив 
і-узлов, индексированный по і-номерам. Элемент і массива указывает на і-узел і на 
диске. Массив хранится на диске, но также содержится и в кэше, так что наиболее ча¬ 
сто используемые части этого массива постоянно находятся в оперативной памяти. 

Таким образом, все операции записи буферизируются в памяти, и периодичес¬ 
ки данные из буфера записываются на диск в виде единых сегментов в конец жур¬ 
нала. Чтобы открыть файл, используется массив, позволяющий обнаружить і-узел 
в файле. Как только і-узел обнаружен, могут быть определены номера блоков фай¬ 
ла. Все эти блоки также располагаются в сегментах где-то в журнале. 

Если бы диски были бесконечного размера, на этом все бы и заканчивалось. 
Однако существующие диски имеют ограниченный размер, поэтому рано или по¬ 
здно журнал займет весь таен. К счастью, многие сегменты, могут содержатъ уже 
ненужные блоки, например, если файл был перезаписан, его і-узел будет указы¬ 
вать на новые блоки, но старые блоки будут все также занимать место в записан¬ 
ных ранее сегментах. 

Для решения проблемы повторного использования блоков в старых сегментах 
у файловой системы ЬЕ5 есть чистящий поток, занимающийся постоянным скани- 
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рованием журнала с целью сделать его более компактным. Он начинает с того, что 
считывает содержание самого первого сегмента журнала, чтобы определить, какие 
і-узлы и файлы находятся в нем. Затем он смотрит в текущий массив і-узлов, про¬ 
веряя, являются ли і-узлы все еще текущими и используются ли все еще блоки 
файлов. Если нет, то эта информация отбрасывается, а все еще использующиеся 
і-узлы и блоки считываются в память, чтобы записать их в следующий сегмент. 
Исходный сегмент помечается как свободный, поэтому журнал может использо¬ 
вать его для новых данных. Таким образом, чистильщик двигается по журналу, 
удаляя старые сегменты с диска и помещая всю имеющую ценность информацию 
в память для перезаписи в следующий сегмент. В результате диск представляет 
собой большой кольцевой буфер, в котором пишущий поток добавляет новые 
сегменты с одного конца, а чистящий процесс удаляет старые сегменты с другого. 

Учет расположения блоков здесь весьма нетривиален, поскольку, когда блок 
файла записывается в новый сегмент, і-узел файла (где-то в журнале) должен быть 
найден, обновлен и помещен в буфер для записи в следующий сегмент. При этом 
массив і-узлов также должен быть обновлен, чтобы элемент массива указывал на 
новую копию. Тем не менее администрирование такой системы вполне возмож¬ 
но, а увеличение производительности показывает, что все эти сложности были не 
напрасны. Приведенные в цитированной выше статье результаты измерений по¬ 
казали, что файловая система с журнальной структурой ЬР5 превосходит систему 
ІЛѴІХ при множестве небольших записях на порядок, а при чтении и больших запи¬ 
сях обладает сходной или лучшей производительностью. 


Примеры файловых систем 

В следующих разделах мы обсудим несколько примеров файловых систем, от 
довольно простых до крайне сложных. Поскольку современные файловые систе¬ 
мы ^NIX и \Ѵтсіо\Ѵ5 2000 будут описываться в отдельных главах этой книги 
(главы 10 и 11), мы не станем обсуждать их здесь. Вместо них мы рассмотрим их 
предшественников. 

Файловые системы СО-НОМ 

В качестве первого примера рассмотрим файловую систему, применяемую на 
СБ-КОМ. Эти системы являются совсем простыми, поскольку они создавались 
для носителей, запись на которые могла производиться только один раз. Кроме 
всего прочего, в этих файловых системах отсутствует учет свободных блоков, так 
как файлы на СБ-КОМ не могут быть удалены или добавлены после того, как диск 
уже изготовлен. Ниже мы рассмотрим основные типы файловых систем для ОБ¬ 
КОМ и два варианта расширения этих систем. 

Файловая система 150 9660 

В 1988 году был принят Международный стандарт 150 9660, описывающий файло¬ 
вые системы для СВ-КОМ. Практически каждый продающийся сегодня СБ-КОМ 
соответствует этому стандарту, иногда согласуясь с его расширениями, которые 
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будут обсуждаться ниже. Одно из назначений этого стандарта заключалось в том, 
чтобы любой СО-КОМ мог быть прочитан на любом компьютере, независимо 
от используемых байтового порядка и операционной системы. Как следствие, на 
файловую систему были наложены определенные ограничения, которые должны 
были позволить читать эти диски даже самым слабым из использовавшихся тогда 
операционных систем (таким как М8-П08). 

У СП-КОМ нет концентрических цилиндров, как у магнитных дисков. Вместо 
этого они содержат непрерывную спираль, на которой последовательно размеще¬ 
ны все биты (хотя поиск поперек спирали также возможен). Биты вдоль спирали 
разделены на логические блоки (также называемые логическими секторами) по 
2352 байт. Некоторые из этих байтов используются для преамбул, коррекции оши¬ 
бок и других накладных расходов. Полезная нагрузка в каждом блоке составляет 
2048 байт. Аудиодиски содержат специальные разделительные участки между 
композициями, а также специальные заголовки и концевики для каждой фоног¬ 
раммы, не используемые в СП-КОМ, содержащих другие данные. Часто позиция 
блока в спирали указывается в минутах и секундах. Она может быть преобразова¬ 
на в линейный номер блока, так как каждая секунда содержит 75 блоков. 

Стандарт 180 9660 также поддерживает наборы размером до 2 16 -1 СП-КОМ. 
Сами СП-КОМ также могут быть разделены на отдельные логические тома (раз¬ 
делы). Однако ниже будет обсуждаться стандарт 180 9660 для одного СП-КОМ, 
не разделенного на тома. 

Каждый СП-КОМ начинается с 16 блоков, чья функция не определяется стан¬ 
дартом 180 9660. Производитель СП-КОМ может использовать эту область для 
размещения загрузчика операционной системы или для другой цели. Следом рас¬ 
полагается один блок, содержащий основной описатель тома, в котором хранится 
некоторая общая информация о СП-КОМ. Среди данных, содержащихся в этом 
блоке, идентификатор системы (32 байт), идентификатор тома (32 байт) иден¬ 
тификатор издателя (128 байт), и идентификатор лица, подготовившего данные 
(128 байт). Производитель диска может заполнить эти поля произвольным обра¬ 
зом, с условием, что он будет использовать только символы верхнего регистра, 
цифры и очень ограниченное количество знаков препинания, чтобы гарантировать 
совместимость с различными платформами. 

Основной описатель тома также содержит имена трех файлов, в которых могут 
храниться краткий обзор, уведомление об авторских правах и библиографическая 
информация соответственно. Кроме того, в этом блоке также содержатся опреде¬ 
ленные ключевые числа, включающие размер логического блока (как правило, 2048, 
однако в определенных случаях могут использоваться блоки большего размера, 
например 4096, 8192 и других степеней двух), количество блоков на СЬ-КОМ, 
а также дата создания и дата окончания срока службы диска. Наконец, основной 
описатель тома также содержит описатель корневого каталога, что позволяет най¬ 
ти этот каталог на СП-КОМ (то есть определить номер блока, содержащего нача¬ 
ло каталога). Начиная с этого каталога, можно определить местонахождение всей 
остальной файловой системы. 

Помимо основного описателя тома, СЭ-КОМ-диск может содержать допол¬ 
нительный описатель тома. В нем хранится информация, сходная с хранящейся 
в основном описателе, но мы не станем рассматривать его в этой книге. 
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Корневой каталог и все остальные каталоги могут содержать переменное коли¬ 
чество записей, в последней из которых установлен специальный бит, помечаю¬ 
щий эту запись как последнюю. Сами каталоговые записи также могут иметь пе¬ 
ременную длину. Каждая запись содержит от 10 до 12 полей, некоторые из них 
содержат текст формата А5СІІ, а другие являются числовыми двоичными полями. 
Двоичные поля кодируются дважды, один раз в формате, используемом в процес¬ 
сорах типа Репііиш (сначала младшие байты, затем старшие), и один раз в форма¬ 
те, используемом в процессоре 5РАК.С (сначала старшие байты, затем младшие). 
Следовательно, 16-разрядное число занимает 4 байт, а 32-разрядное число 8 байт. 
Такое избыточное кодирование было использовано при разработке стандарта, что¬ 
бы никого не обидеть. Если бы стандарт учитывал только один из способов хране¬ 
ния двоичного числа, тогда сотрудники компаний, в которых применяется другой 
способ, посчитали бы, что их отнесли к гражданам второго сорта и не приняли бы 
стандарт. Таким образом, эмоциональное содержание СЭ-КОМ может быть точ¬ 
но измерено в килобайтах потерянного пространства. 

Формат каталоговой записи стандарта 180 9660 показан на рис. 6.26. Поскольку 
каталоговые записи могут быть переменной длины, первое поле записи представ¬ 
ляет собой байт, содержащий длину записи. Во избежание любых двусмысленно¬ 
стей стандартом определено, что старший бит этого байта располагается слева. 
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Рис. 6.26. Каталоговая запись стандарта 150 9660 


Записи каталогов могут иметь расширенные атрибуты. Если для каталоговой 
записи используется это свойство, тогда второй байт содержит длину записи рас¬ 
ширенных атрибутов. 

Следом располагается номер начального блока файла. Файлы хранятся на дис¬ 
ке в виде непрерывных последовательностей блоков, так что размещение файла 
на диске однозначно определяется начальным блоком и размером, значение кото¬ 
рого содержится в следующем поле. 

В следующем поле хранятся дата и время записи СЭ-КОМ 1 . Значения года, 
месяца, дня, часа, минуты, секунды и временной зоны хранятся в отдельных бай¬ 
тах. Годы отсчитываются от 1900, что означает, что СЭ-КОМ будут страдать от 
проблемы 2156 года, так как следом за 2155 годом для них наступит 1900 год. 
Возникновение этой проблемы можно было отложить на 88 лет, приняв за точку 
отсчета 1988 (год принятия стандарта). Если бы это было сделано, проблему можно 
было бы отложить до 2244 года. 


Вернее, дата и время создания файла. — Примеч. перев. 
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Поле На§з (флаги) содержит несколько различных управляющих битов, один 
из которых позволяет скрывать запись при отображении каталога (свойство, взя¬ 
тое из М5-Б05), другой разрешает использование расширенных атрибутов, а тре¬ 
тий помечает последнюю запись в каталоге. Мы не станем рассматривать здесь 
остальные биты этого поля. Следующее поле описывает особенности чередования 
частей файла на диске. Это свойство не используется в простейшей версии стан¬ 
дарта 150 9660, поэтому оно не будет обсуждаться в данной книге. 

Еще одно поле указывает местоположение файла на СБ-КОМ. Стандарт допус¬ 
кает возможность расположения файла на другом СБ-КОМ набора. Таким обра¬ 
зом, можно создать на одном СБ-КОМ главный каталог, содержащий все файлы 
всех остальных СБ-КОМ набора. 

Поле, отмеченное на рис. 6.26 символом I, содержит длину имени файла в бай¬ 
тах. За ним следует само имя файла, состоящее из базового имени (Ьазе пате на 
рисунке), точки, расширения, точки с запятой и версии файла в двоичном форма¬ 
те (один или два байта). В базовом имени и расширении могут использоваться 
прописные символы, цифры от 0 до 9 и символ подчеркивания. Все остальные сим¬ 
волы запрещены, чтобы гарантировать, что каждый компьютер сможет работать 
со всеми файлами на диске. Базовое имя может быть длиной до восьми символов; 
расширение — до трех символов. Такой выбор был продиктован необходимостью 
совместимости с системой М5-В05. Имя файла может встречаться несколько раз, 
но с различными номерами версий. 

Последние два поля не всегда присутствуют. Поле РаМіщ (заполнение) ис¬ 
пользуется для выравнивания размера каталоговой записи до четного количества 
байтов, чтобы выровнять записи в каталоге по 2-байтовым границам. Если требу¬ 
ется выравнивание, используется нулевой байт. Наконец, функция и размер 
последнего поля Зузіет изе (5уз на рисунке) никак не определяются стандартом. 
В стандарте указывается лишь, что это поле должно состоять из четного числа бай¬ 
тов. В различных операционных системах это поле используется различным обра¬ 
зом. Например, МасіпГозЬ хранит в этом поле флаги Еіпбег. 

Все записи каталога, кроме первых двух, располагаются в алфавитном поряд¬ 
ке. Первая запись представляет собой описатель самого каталога. Вторая запись 
является ссылкой на родительский каталог. В этом смысле эти записи аналогич¬ 
ны каталоговым записям «.» и «..» в ЕГЫІХ. 

Количество каталоговых записей не ограничено. Однако существует ограниче¬ 
ние глубины вложенности каталогов. Максимальная глубина вложенности ката¬ 
логов равна восьми. 

Стандартом 150 9660 определены так называемые три уровня. На уровне 1 при¬ 
меняются самые жесткие ограничения. Имена файлов ограничиваются уже опи¬ 
санной выше схемой 8 + 3, а имена каталогов могут состоять из восьми символов 
и не могут иметь расширений. Кроме того, уровень 1 требует, чтобы все файлы 
были непрерывными. Использование этого уровня обеспечивает совместимость 
СБ-КОМ с самым широким спектром систем. 

Уровень 2 ослабляет ограничение на длину имени. Он позволяет файлам и ката¬ 
логам иметь имена до 31 символа, но из того же набора символов. 
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На уровне 3 используются те же ограничения имен, что и на уровне 2, но ос¬ 
лабляется жесткость требования непрерывности файлов. На этом уровне файл 
может состоять из нескольких разделов, каждый из которых представляет собой 
непрерывную последовательность блоков. Одна и та же последовательность бло¬ 
ков может несколько раз встречаться в одном файле и даже входить в несколько 
различных файлов. Такая организация файловой системы позволяет экономить 
место на диске. 

Рок-Ридж расширения 

Как было показано, стандарт 150 9660 содержит много различных ограничений. 
Вскоре после выхода этого стандарта пользователи из ІЗХІХ-сообщества начали 
работу над его расширением, чтобы файловая система ІІХІХ могла быть представ¬ 
лена на СО-КОМ. Эти расширения получили название Рок-Ридж (Коек Кіб§е) 
по городу из фильма Джина Уайлдера Віагіщ Засісііех (Огненные седла), вероят¬ 
но, потому, что этот фильм нравился одному из членов комитета. 

Расширение использует поле 5у$1ет и$е, чтобы СО-КОМ формата Рок-Ридж 
мог читаться на любом компьютере. Все остальные поля соответствуют требова¬ 
ниям стандарта 150 9660. Система, не знакомая с расширениями Рок-Ридж, про¬ 
сто игнорирует их и видит нормальный СО-КОМ. 

Расширения содержат следующие поля: 

1. РХ — Атрибуты Р05ІХ. 

2. РХ — Старший и младший номера устройств. 

3. 5Ь — Символьная связь. 

4. ХМ — Альтернативное имя. 

5. СЬ — Расположение дочернего узла. 

6. РЬ — Расположение дочернего узла. 

7. КЕ — Перераспределение. 

8. ТЕ — Временные штампы. 

Поле РХ содержит стандартные биты разрешений тхтхпюх системы ІІХІХ для 
владельца, группы и всех остальных. Оно также содержит остальные биты слова 
состояния, такие как 5ЕТШО, 5ЕТСЮ ит. п. 

Чтобы необработанные устройства могли быть представлены на СО-КОМ, 
вводится поле РХ. Оно содержит старший и младший номера устройств, ассоции¬ 
рованных с файлом. Таким образом, содержимое каталога /сіе.ѵ может быть запи¬ 
сано на СО-КОМ и позднее правильно воссоздано на другой системе. 

Поле 5Ь используется для символьных связей. Оно позволяет файлу из одной 
файловой системы ссылаться на файл из другой файловой системы. 

Вероятно, наиболее важным является поле ИМ. С его помощью можно указать 
для файла второе имя. Этого имени не касаются ограничения стандарта 150 9660, 
что позволяет указывать произвольные имена файлов системы ІІХІХ на СО-КОМ. 

Следующие три поля используются вместе, чтобы обойти ограничения стан¬ 
дарта 150 9660 на глубину вложенности каталогов. С их помощью можно указать, 
куда в дереве иерархии должен быть перемещен тот или иной каталог. 
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Наконец, поле ТР содержит три временных штампа, включаемые в каждый і-узел 
системы ІШІХ, а именно: время создания файла, последнего изменения файла 
и последнего доступа к файлу. Все вместе эти расширения позволяют скопировать 
файловую систему ІШІХ на СО-КОМ, а затем корректно восстановить ее на дру¬ 
гой машине. 

Расширения иоііеі 

Сообщество ІШІХ было не единственной группой, которой требовалось расшире¬ 
ние стандарта 150 9660. Корпорация МісгозоЙ также пришла к выводу, что стан¬ 
дарт 150 9660 содержит слишком много ограничений (хотя большинство ограни¬ 
чений было вызвано в первую очередь требованием совместимости с файловой 
системой М5-005 фирмы Місгозоіі). Поэтому корпорация Місгозоіі: разработала 
некоторые расширения, названные ^Ііеі. Они должны были позволить копи¬ 
ровать на СО-КОМ-диск и восстанавливать с него файловую систему \Ѵіп<Іо\ѵз 
подобно тому, как расширения Рок-Ридж позволяли работать с файловой систе¬ 
мой ІШІХ. Теоретически все программы, работающие в операционной системе 
\Ѵіп<Іо\ѵз и использующие СО-КОМ, включая программы записи на СО-К, под¬ 
держивают расширение }о1іеІ. 

Основными расширениями, содержащимися в }о1іеІ, являются: 

1. Длинные имена файлов. 

2. Набор символов ІІпісоЗе. 

3. Глубина вложенности каталогов, превышающая восемь уровней. 

4. Имена каталогов с расширениями. 

Первое расширение позволяет использовать имена файлов длиной до 64 сим¬ 
волов. Второе расширение разрешает использовать для имен файлов символы 
ІіпісоЗе. Это расширение важно для программного обеспечения, предназначенно¬ 
го для распространения в странах, в которых не используется латинский алфавит, 
таких как Япония, Израиль или Греция’. Поскольку символы ГІпісосІе занимают 
два байта, максимальное имя файла в расширении Доііеі занимает 128 байт. 

Как и Рок-Ридж, расширение Д оііеі; устраняет ограничение на глубину вложен¬ 
ности каталогов. Каталоги могут вкладываться друг в друга на любую требуемую 
глубину. Наконец, у имен каталогов могут быть расширения. Неясно, почему было 
включено такое расширение стандарта, поскольку каталоги в файловой системе 
'ІУіпЗоѵѵз практически никогда не используют расширений, но, возможно, однаж¬ 
ды они потребуются. 

Файловая система СР/М 

Первые персональные компьютеры (называвшиеся тогда мини-компьютерами) 
появились в начале 80-х годов. В одной популярной модели персонального компь¬ 
ютера использовался 8-разрядный центральный процессор ІгшеІ 8080. У этого компь¬ 
ютера было 4 Кбайт ОЗУ и один 8-дюймовый накопитель для сменных гибких дис¬ 
ков емкостью 180 Кбайт. В более поздних версиях этой машины применялся 


1 И Россия. — Примеч. перев. 
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несколько более мощный (хотя все равно 8-разрядный) процессор 2і1о§ 280. У него 
было до 64 Кбайт ОЗУ и огромный 720-килобайтный гибкий диск в качестве 
основного устройства хранения данных. Несмотря на невысокое быстродей¬ 
ствие и небольшое количество памяти, почти на всех этих машинах работала 
удивительно мощная дисковая операционная система СР/М (Сопігоі Рго§гаш Іог 
Місгосошриіегз — управляющая программа для микрокомпьютеров) [130]. Эта 
операционная система была доминирующей в свою эпоху, так же как МЗ-БОЗ и 
позднее ^іпбошз стали лидерами в мире ІВМ РС. Двадцать лет спустя она исчез¬ 
ла, не оставив следа (если не считать малочисленной группы твердокаменных сто¬ 
ронников), и это наводит на мысль о том, что системы, лидирующие сегодня в мире 
(например, ^іпсіоѵѵз), могут оказаться никому неизвестными к тому времени, ког¬ 
да сегодняшние карапузы станут студентами колледжей. 

Стоит взглянуть на операционную систему СР/М по нескольким причинам. 
Во-первых, исторически это была очень важная система, ставшая прямым предше¬ 
ственником системы М5-Э05. Во-вторых, разработчики сегодняшних операцион¬ 
ных систем и систем будущего, полагающие, что компьютеру требуется 32 Мбайт 
памяти, только чтобы загрузить в нее операционную систему, могут поучиться про¬ 
стоте системы, которой вполне хватало 16 Кбайт ОЗУ. В-третьих, в ближайшие 
десятилетия широкое применение получат встроенные системы. В связи с огра¬ 
ничениями в цене, размерах, весе и потребляемой мощности операционные систе¬ 
мы, используемые, например, в часах, видео- и фотокамерах, радиоприемниках и 
сотовых телефонах, обязательно должны быть компактными, подобно операцион¬ 
ной системе СР/М. Конечно, у этих систем не будет 8-дюймовых гибких дисков, 
но они вполне могут пользоваться электронными дисками во флэш-ОЗУ, на кото¬ 
рых несложно организовать файловую систему, подобную СР/М. 

Распределение памяти в системе СР/М показано на рис. 6.27. Наверху оператив¬ 
ной памяти (в ОЗУ) располагается базовая система ввода-вывода ВІ05, содержащая 
базовую библиотеку — 17 вызовов ввода-вывода, используемых системой СР/М 
(в данном разделе мы рассмотрим СР/М 2.2, являвшуюся стандартной версией, 
когда СР/М была на вершине популярности). Эти системные вызовы предназна¬ 
чены для чтения и записи с гибкого диска, ввода с клавиатуры и вывода на экран. 


Адрес 
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Рис. 6.27. Распределение памяти в системе СР/М 
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Сразу под ВЮ5 располагается сама операционная система. Для версии СР/М 2.2 
ее размер составляет 3584 байт. Невероятно, но факт: вся операционная система 
занимала менее 4 Кбайт. Под операционной системой размещается оболочка (обра¬ 
ботчик командных строк), съедающая еще 2 Кбайт. Остальная память используется 
для программ пользователя, кроме нижних 256 байт, зарезервированных для векто¬ 
ров аппаратных прерываний, некоторых переменных и буфера для текущей команд¬ 
ной строки, в котором к ней могут получить доступ программы пользователя. 

Причина, по которой система ВЮ8 отделена от самой операционной системы 
СР/М (хотя обе системы располагаются в ОЗУ), заключается в переносимости. 
Операционная система СР/М взаимодействует с аппаратурой только с помощью 
обращений к ВЮ8. Для переноса системы СР/М на новую машину нужно всего 
лишь перенести туда ВЮ8. Когда это сделано, сама СР/М может быть установле¬ 
на без изменений. 

В файловой системе СР/М всего один каталог, содержащий записи фиксиро¬ 
ванного размера (32 байт). Размер каталога, фиксированный для данной реали¬ 
зации, может отличаться в других реализациях системы СР/М. В этом каталоге 
перечисляются все файлы системы. После загрузки система считывает каталог 
и рассчитывает битовый массив занятых и свободных блоков. Этот битовый мас¬ 
сив, размер которого для 180-килобайтного диска составляет всего 23 байта, по¬ 
стоянно хранится в оперативной памяти. После завершения работы операционной 
системы он не сохраняется на диске. Благодаря такому подходу исчезает необ¬ 
ходимость в проверке 1 непротиворечивости файловой системы на диске (вроде 
той, что выполняет программа /зек в ІЖІХ) и сохраняется на диске один блок 
(в процентном отношении это эквивалентно сохранению 90 Мбайт на современ¬ 
ном 16-гигабайтном диске). 

Когда пользователь набирает команду, оболочка сначала копирует ее в буфер 
в нижние 256 байт памяти. Затем она ищет вызываемую программу и загружает ее 
в память по адресу 256 (над вектором прерываний), после чего передает управле¬ 
ние по этому адресу. Программа начинает работу. Она обнаруживает свои пара¬ 
метры в буфере командной строки. Программе разрешается использовать память, 
занимаемую оболочкой, если ей нужно много памяти. Закончив работу, про¬ 
грамма выполняет системный вызов СР/М, сообщая операционной системе, что 
следует перезагрузить оболочку (если занимаемая ею память использовалась про¬ 
граммой) и запустить ее. В двух словах, вот, собственно, и весь рассказ об опера¬ 
ционной системе СР/М. 

Помимо загрузки программ, система СР/М предоставляет программам пользо¬ 
вателя 38 системных вызовов, большей частью относящихся к файловой службе. 
Наиболее важными из них являются системные вызовы чтения из файла и записи 
в файл. Прежде чем файл может быть прочитан, его следует открыть. Когда СР/М 
получает системный вызов орел, она должна прочитать свой единственный ката¬ 
лог и найти в нем требуемый файл. Для экономии драгоценной памяти этот ката¬ 
лог не хранится в ОЗУ постоянно. Когда СР/М обнаруживает описатель файла, 
она сразу же получает содержащиеся прямо в нем номера дисковых блоков файла, 
а также все остальные атрибуты. Формат каталоговой записи показан на рис. 6.28. 

1 В результате сбоя файлы могут пересечься, то есть один и тот же блок может оказаться сразу в двух 
файлах. Так что проверка все равно нужна. Например, при загрузке операционной системы. — При- 
меч. перед. 
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Байты 1 8 3 12 -»-16 



Рис. 6.28. Формат каталоговой записи в системе СР/М 


Значение полей на рис. 6.28 следующее. Поле ІІзег сойе (код пользователя) 
указывает владельца файла. Хотя в каждый конкретный момент времени в систе¬ 
ме СР/М может находиться лишь один пользователь, системой поддерживается 
поочередная работа нескольких пользователей. При поиске имени файла файло¬ 
вая система проверяет только записи, принадлежащие текущему зарегистрировав¬ 
шемуся пользователю. В результате каждый пользователь получает свой вирту¬ 
альный каталог без необходимости управлять несколькими каталогами. 

В следующих двух полях содержатся имя и расширение файла. Размер базового 
имени может быть до восьми символов. Также может использоваться (необязатель¬ 
ное) расширение файла длиной до трех символов. Формат имени файла из 8 + 3 сим¬ 
волов верхнего регистра был позднее заимствован в МЗ-БОЗ. 

Поле Віоск соипі (счетчик блоков) содержит размер файла, измеренный в еди¬ 
ницах по 128 байт (так как ввод-вывод выполняется в 128-байтовых 1 физических 
секторах). Последний килобайтный блок файла может быть заполнен не до конца, 
поэтому у системы нет способа определить точный размер файла. Конец файла 
может быть при необходимости указан пользователям с помощью специального 
маркера. Последние 16 полей содержат сами номера дисковых блоков, занимае¬ 
мых файлом. Размер каждого блока 1 Кбайт, поэтому максимальный размер фай¬ 
ла равен 16 Кбайт. Обратите внимание, что физический ввод-вывод выполняется 
в 128-байтовых секторах и размер файла хранится в 128-байтовых секторах, но 
файлам выделяются блоки размером по 1 Кбайт (сразу по 8 секторов), чтобы не 
увеличивать размер каталоговой записи. 

Однако разработчик системы СР/М понимал, что некоторые файлы, даже на 
180-килобайтном гибком диске, могут превзойти размер 16 Кбайт, поэтому для 
обхода 16-килобайтного ограничения был придуман следующий трюк. Для файла 
размером от 16 до 32 Кбайт используется не одна каталоговая запись, а две. В пер¬ 
вой записи содержатся номера первых 16 блоков диска; во второй записи — следу¬ 
ющие 16 блоков. При превышении файлом 32 Кбайт требуется третья каталого¬ 
вая запись и т. д. Порядковый номер каталоговой записи хранится в поле ЕхСепІ 
(экстент), благодаря которому операционная система может определить, какие 
16 Кбайт находятся в начале файла, какие идут следом и т. д. 

После того как системный вызов ореп выполнен, адреса всех дисковых блоков 
становятся известны, поэтому реализация системного вызова геасі не представля- 

1 Малый размер физических блоков (128 байт) значительно замедляет операции ввода-вывода, тогда 
как большой размер кластеров (1 Кбайт) сильно снижает эффективность использования дискового 
пространства. Поэтому лучше было бы сделать наоборот, то есть физические блоки по 1 Кбайт, а ло¬ 
гические — по 128 или 256 байт. — Примеч. перед. 
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ет сложности. Системный вызов мгНе также прост. Для этого требуется всего лишь 
выделение файлу нового свободного блока из битового массива, хранящегося 
в оперативной памяти, и запись блока. Последовательные блоки файла не распо¬ 
лагаются последовательно на диске, так как центральный процессор Іпіеі 8080 не 
успевает обработать прерывание и начать чтение следующего блока. Вместо этого 
используется чередование блоков, позволяющее считывать несколько блоков за 
один оборот диска. 

Система СР/М, очевидно, не является последним словом в области современ¬ 
ных файловых систем, но она отличается своей простотой, скоростью и может быть 
реализована компетентным программистом менее чем за неделю. Для многих 
встроенных приложений, возможно, большего и не требуется. 


Файловая система М8-Р08 

В первом приближении файловая система М5-Б05 представляет собой увеличен¬ 
ную и улучшенную версию СР/М. Она работает только на платформах с централь¬ 
ным процессором ІпРеІ, не поддерживает многозадачности и работает лишь в ре¬ 
альном режиме ІВМ РС (изначально этот режим был единственным режимом). 
Оболочка содержит больше возможностей, чем в СР/М, системных вызовов тоже 
больше в МЗ-БОЗ, но основной функцией операционной системы все также оста¬ 
ется загрузка программ, управление экраном, обработка ввода с клавиатуры и уп¬ 
равление файловой системой. Именно последняя функция и будет интересовать 
нас в данной главе. 

Файловая система М5-Б05 во многом напоминает файловую систему СР/М, 
включая использование имен файлов, состоящих из 8 + 3 символов верхнего ре¬ 
гистра. В первой версии системы (М5-И05 1.0) был даже всего один каталог, как 
и в СР/М. Однако, начиная с М5-Б05 2.0, функциональность файловой систе¬ 
мы значительно расширилась. Самым серьезным улучшением явился переход на 
иерархическую файловую систему, в которой каталоги могли вкладываться друг 
в друга на произвольную глубину. Это означало, что корневой каталог (размер 
которого по-прежнему был ограничен) мог содержать подкаталоги, которые, в свою 
очередь, также могли содержать подкаталоги и т. д. до бесконечности. Связи, при¬ 
нятые в ІШІХ, не допускались, поэтому файловая система представляла собой 
дерево, начинавшееся в корневом каталоге. 

Различные прикладные программы довольно часто начинают с того, что со¬ 
здают в корневом каталоге подкаталог, в который складывают все свои файлы, 
что позволяет программам избежать конфликта. Так как сами каталоги хранятся 
в М5-Б05 как файлы, нет никакого ограничения на число каталогов или файлов 
на диске. Однако в отличие от СР/М, в М5-Б05 нет концепции различных пользо¬ 
вателей. Соответственно, любой вошедший в систему пользователь получает дос¬ 
туп сразу ко всем файлам. 

Чтобы прочитать файл, программа, работающая в системе М5-005, должна 
сначала сделать системный вызов орел, чтобы получить дескриптор файла. Сис¬ 
темному вызову орел в качестве одного из входных аргументов следует указать путь 
к файлу, который может быть как абсолютным, так и относительным (относи¬ 
тельно текущего каталога). Файловая система открывает каталоги, перечисленные 
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в пути, один за другим, пока не обнаруживает последний каталог, который считы¬ 
вается в оперативную память. Затем в считанном каталоге ищется описатель фай¬ 
ла, который требуется открыть. 

Хотя каталоги в файловой системе М5-005 переменного размера, используе¬ 
мые каталоговые записи, как и в СР/М, имеют фиксированный размер 32 байт. 
Формат описателя файла системы М5-005 показан на рис. 6.29. В нем содержит¬ 
ся имя файла, его атрибуты, дата и время создания, номер начального блока и точ¬ 
ный размер файла. Имена файлов короче 8 + 3 символов выравниваются по лево¬ 
му краю полей и дополняются пробелами, каждое поле отдельно. Поле АйгіЪиІе $ 
(атрибуты) представляет собой новое поле, содержащее биты, указывающие, что для 
файла разрешено только чтение, что файл должен быть заархивирован, что файл 
является системным или скрытым. Запись в файл, для которого разрешено только 
чтение, не разрешается. Таким образом осуществляется защита файлов от случай¬ 
ной записи или удаления. Бит аіѵкіѵесі (архивный) не устанавливается и не про¬ 
веряется операционной системой М5-Б05. Он зарезервирован в описателе для 
архивирующих программ уровня пользователя, сбрасывающих этот бит при созда¬ 
нии резервной копии файла, в то время как программы, модифицирующие файл, 
должны устанавливать этот бит. Таким образом архивирующая программа может 
определить, какие файлы подлежат архивации. Бит ЫМеп (скрытый файл) позво¬ 
ляет избежать отображения файла в перечне файлов каталога. Основное его на¬ 
значение заключается в том, чтобы скрыть от неопытных пользователей файлы, 
назначение которых им неизвестно. Наконец, бит хухіет (системный) также скры¬ 
вает файлы и защищает их от случайного удаления командой сіеі. Этот бит уста¬ 
новлен у основных компонентов системы М5-005. 
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Рис. 6.29. Формат каталоговой записи в системе МЗ-РОЗ 


Каталоговая запись также содержит дату и время создания или последнего из¬ 
менения файла. Время хранится с точностью ±2 с 1 , так как для него отведено 2-бай- 
товое поле, способное содержать всего 65 536 уникальных значений, а в сутках 
86 400 с. Поле времени разбивается на подполя секунд (5 бит), минут (6 бит) и ча¬ 
сов (5 бит). 16-разрядное поле даты также разбивается на три подполя: день (5 бит), 
месяц (4 бит) и год — 1980 (7 бит). При 7 двоичных разрядах для хранения года 
и 1980 в качестве точки отсчета максимальное значение года, которое можно вы¬ 
разить таким способом, — это 2107-й. Таким образом, файловая система М5-005 
имеет встроенную проблему 2108 года. Чтобы избежать катастрофы, пользовате¬ 
ли системы М5-005 должны начать готовиться к 2108 году как можно раньше. 
Если бы в М5-Б05 использовался единый 32-разрядный счетчик секунд, точность 


Точнее, ±1 с, то есть с шагом в 2 с. — Примем, перев. 
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представления времени была бы в два раза выше, а катастрофу можно было бы 
отложить до 2116 года. 

В отличие от файловой системы СР/М, не хранящей точного размера файла, 
система М8-Э08 хранит точный размер. Поскольку для размера файла использу¬ 
ется 32-разрядное число, в теории файлы могут быть размером до 4 Гбайт. Однако 
другие пределы (описываемые ниже) ограничивают максимальный размер фай¬ 
ла размером 2 Гбайт или меньше. Удивительно большая часть описателя файла 
(10 байт) не используется. 

Другое отличие системы М8-Э08 от СР/М состоит в том, что дисковые адре¬ 
са файлов не хранятся прямо в их описателях, возможно, поскольку разработчики 
системы понимали, что большие жесткие диски (обычные в то время на мини-ком¬ 
пьютерах) однажды появятся в мире М8-Э08. Вместо этого файловая система 
М8-Б08 хранит номера блоков файла в специальной таблице размещения файлов, 
в оперативной памяти. В каталоговой записи хранится номер первого блока фай¬ 
ла. Этот номер используется в качестве индекса для 64 К 1 элементов РАТ-табли- 
цы, хранящейся в оперативной памяти. Все блоки файла могут быть найдены, если 
проследовать по цепочке элементов таблицы. Принцип действия РАТ-таблицы 
проиллюстрирован на рис. 6.11. 

В зависимости от количества блоков на диске в системе М8-Б08 применяется 
три версии файловой системы РАТ: РАТ-12, РАТ-16 и РАТ-32. В действительнос¬ 
ти РАТ-32 является неверным названием, так как используются только 28 млад¬ 
ших битов дискового адреса. Ее следовало бы назвать РАТ-28, но степени двух зву¬ 
чат гораздо приятнее. 

Во всех файловых системах РАТ размер блока диска в байтах может быть уста¬ 
новлен равным некоторому числу, кратному 512 (возможно, различному для каж¬ 
дого раздела диска), с наборами разрешенных размеров блоков (называемых кор¬ 
порацией МісгозоіГ размерами кластеров), различными для каждого варианта 
РАТ. В первой версии системы М8-Э08 использовалась РАТ-12 с 512-байтовы¬ 
ми блоками, что позволяло создавать дисковые разделы размером до 2 12 х 512 байт 
(на самом деле только 4086 х 512 байт, так как 10 дисковых адресов использова¬ 
лись как специальные маркеры — конец файла, дефектный блок и т. д.). При этом 
максимальный размер дискового раздела мог составлять 2 Мбайт, а в оперативной 
памяти РАТ-таблица занимала 4096 элементов по два байта каждый. Кроме того, 
обработка 12-разрядных адресов была довольно медленной. 

Такая система неплохо работала на гибких дисках, но с появлением жестких 
дисков появились проблемы. Корпорация МісгозоФ попыталась решить пробле¬ 
му, разрешив использовать дисковые блоки (кластеры) размером 1, 2 и 4 Кбайт. 
Это позволило сохранить структуру и размер таблицы РАТ-12 и увеличить раз¬ 
мер дискового раздела до 16 Мбайт. 

Так как система М8-В08 поддерживала до четырех дисковых разделов на диске, 
новая файловая система РАТ-12 могла работать с дисками емкостью до 64 Мбайт. 
Для поддержки винчестеров большего размера нужно было предпринимать что-то 
еще. В результате была разработана файловая система РАТ-16, с 16-разрядными 

1 Справедливо только для РАТ-16. Например, для РАТ-12, до сих пор применяющейся для гибких 
дисков, таблица содержит 2 12 - 4096 элементов. Для РАТ-32 размер таблицы во много раз превы¬ 
шает 64 К. — Примеч. перев. 
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дисковыми указателями. Дополнительно было разрешено использовать кластеры 
размеров 8, 16 и 32 Кбайт. (32 768 — это максимальное число, представляющее 
собой степень двух, которое может быть представлено 16 двоичными разрядами.) 
Теперь таблица РАТ-16 постоянно занимала 128 Кбайт оперативной памяти, но 
с ростом размеров памяти компьютеров она получила широкое применение и бы¬ 
стро вытеснила файловую систему РАТ-12. Максимальный размер дискового 
раздела, поддерживаемый системой РАТ-16, равен 2 Гбайт (64 К элементов по 
32 Кбайт каждый), а максимальный размер диска — 8 Гбайт, то есть четыре разде¬ 
ла по 2 Гбайт каждый. 

Для хранения деловой переписки такое ограничение проблем не вызывает, 
однако при работе с цифровым видео в стандарте БѴ один 2-гигабайтный файл 
вмещает всего лишь немногим более 9 мин видеофильма. Таким образом, на весь 
диск из четырех разделов может поместиться около 38 мин видео, независимо 
от размеров самого диска. Это ограничение также означает, что в режиме оп-1іпе 
редактировать можно не более 19 мин фильма, так как на диске требуется одно¬ 
временно хранить и входные и выходные файлы. 

С выходом второй версии операционной системы \Уіп<1о\Ѵ5 95 была представ¬ 
лена файловая система РАТ-32 со своими 28-разрядными адресами. При этом вер¬ 
сия системы М5-005, лежащая в основе \Ѵіпс1о\ѵз 95, была адаптирована для под¬ 
держки РАТ-32. Теоретически в этой системе разделы могли быть по 2 28 х 2 15 байт, 
но фактически размер разделов ограничен 2 Тбайт (2048 Гбайт), так как внут¬ 
ренне система учитывает размеры разделов в 512-байтовых секторах с помощью 
32-разрядных чисел, а 2 32 х 2 9 байт равно 2 Тбайт. Максимальный размер раздела 
для всех трех типов РАТ и различных размеров кластеров показан в табл. 6.3. 
Пустым элементам таблицы соответствуют запрещенные комбинации. 

Таблица 6.3. Максимальный размер раздела для различных размеров кластеров 


Размер кластера, Кбайт РАТ-12, Мбайт РАТ-16, Мбайт РАТ-32, Тбайт 
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Помимо поддержки дисков большего размера, файловая система РАТ-32 об¬ 
ладает двумя другими преимуществами перед системой РАТ-16. Во-первых, 8-ги¬ 
габайтный диск, использующий РАТ-32, может состоять из всего одного раздела. 
При использовании РАТ-16 он должен был содержать четыре раздела, что пред¬ 
ставлялось пользователям системы 'ІѴіпбоѵз как логические устройства С:, й:, Е: 
и Р:. Какой файл на каком устройстве располагать, решать пользователю. 

Другое преимущество РАТ-32 перед РАТ-16 заключается в том, что для диско¬ 
вого раздела заданного размера могут использоваться блоки меньшего размера. 
Например, для 2-гигабайтного дискового раздела система РАТ -16 должна пользо- 
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ваться 32-килобайтными блоками, в противном случае при наличии всего 64 К 
доступных дисковых адресов она не смогла бы покрыть весь раздел. В то же время 
система РАТ-32 для такого же дискового раздела может использовать, например, 
блоки размером 4 Кбайт. Преимущество блоков меньшего размера заключается 
в том, что длина большинства файлов менее 32 Кбайт. При размере блока в 32 Кбайт 
даже 10-байтовый файл будет занимать на диске 32 Кбайт. Если средний размер 
файлов, скажем, равен 8 Кбайт, тогда при использовании 32-килобайтных блоков 
около 3/4 дискового пространства будет теряться, то есть эффективность использо¬ 
вания диска будет низкой. При 8-килобайтных файлах и 4-килобайтных блоках 
потерь дискового пространства не будет, но платой за это будет то, что для хра¬ 
нения таблицы РАТ потребуется значительно больше оперативной памяти. При 
4-килобайтных блоках 2-гигабайтный раздел будет состоять из 512 К блоков, по¬ 
этому таблица РАТ должна состоять из 512 К элементов (занимая 2 Мбайт ОЗУ). 

Файловая система М5-Э05 использует РАТ для учета свободных блоков. 
Любой незанятый блок помечается специальным кодом. Когда системе М5-П05 
требуется новый блок на диске, она ищет этот код в таблице РАТ. Таким образом, 
битовый массив или список свободных блоков не нужны. 

Файловая система ѴѴіпсІоѵѵз 98 

Первая версия операционной системы 'ІѴіпсІоѵѵз 95 использовала файловую сис¬ 
тему М5-П05, с именами файлов из 8 + 3 символов и системами РАТ-12 и РАТ-16. 
Начиная со второй версии системы \Ѵіпс1о\ѵз 95, были разрешены более длинные 
имена файлов. Кроме того, была представлена система РАТ-32, в первую очередь 
для поддержки дисков размером более 8 Гбайт и дисковых разделов, больших, чем 
2 Гбайт. Та же файловая система была использована в системе \Уіпс1о\ѵ5 98. Ниже 
будут описаны эти особенности файловой системы ^Ѵіпсіохѵз 98, также применяю¬ 
щейся в системе 'ІУіпйоѵѵз Ме. 

Поскольку длинные имена файлов производят на пользователей более силь¬ 
ное впечатление, чем структура РАТ, рассмотрим их в первую очередь. Для того 
чтобы позволить пользователям работать с длинными именами файлов, можно 
было просто разработать новую структуру каталога. Недостаток такого подхода 
состоит в том, что если бы корпорация МісгозоЙ сделала это, пользователи, до сих 
пор переходящие с \Уіпс1о\ѵ5 3 на ^Ѵіпсіохѵз 95 или ^Ѵіпйоѵѵз 98, не смогли бы 
иметь доступ ко всем своим файлам одновременно из обеих систем. В корпорации 
Місго5о11 было принято политическое решение о том, что файлы, созданные в си¬ 
стеме \Уіпс1о\ѵ5 98, должны быть также доступны из \Ѵіпс1о\ѵз 3 (для машин с двой¬ 
ной загрузкой). В результате была разработана система поддержки длинных имен, 
обладавшая обратной совместимостью со старой системой имен 8 + 3, применяв¬ 
шейся в М5-008. Поскольку такие требования обратной совместимости нередки 
в компьютерной промышленности, стоит детально ознакомиться с тем, как корпо¬ 
рация МісгозоД выполнила эту задачу. 

Итак, каталоговая структура системы 'ІѴіпйоѵѵз 98 должна была обладать обрат¬ 
ной совместимостью со структурой каталогов М8-005. Как уже было показано, 
эта структура представляет собой просто список 32-байтовых описателей (рис. 6.30). 
Такой формат был заимствован у файловой системы СР/М (написанной для про- 
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цессора Іпіеі 8080), что демонстрирует, насколько долго структуры (устаревшие) 
могут существовать в компьютерном мире. 

Однако в 32-байтовом описателе файла оставались незадействованными 10 байт 
(см. рис. 6.29), что и было использовано. Это изменение не имеет никакого отно¬ 
шения к длинным именам, но используется в \ѴіпсІо\ѵ5 98, поэтому стоит обратить 
на него внимание. 


Байты 8 31114 2 2 4 24 


Базовое имя 


Расширение 


N 

Дата/время 

Дата последнего 

Т 

создания 

доступа 


Дата/время 

последней 

записи 


Размер 

файла 


/ / 

Атрибуты 5ес 


* 


і 


Старшие 16 бит 
номер начального 
блока 


Младшие 16 бит 
номер начального 
блока 


Рис. 6.30. Формат каталоговой записи в системе МЗ-РОЗ 


Изменение каталоговой записи состоит в добавлении пяти новых полей на 
место неиспользовавшихся 10 байт. Поле ЫТ предназначено для совместимости 
с \ѴіпсІо\ѵ5 ЫТ и обеспечивает отображение имени файла в правильном регистре. 
Поле 5ес решает проблему невозможности хранения времени суток в 16-битовом 
поле с точностью до секунды. Восемь дополнительных разрядов позволяют хранить 
поле Сгеайоп ііте (время создания) с точностью до 10 мс. Еще одно новое поле Еаві 
ассевв (дата последнего доступа) хранит дату (но не время) последнего доступа к 
файлу. Наконец, переход на файловую систему РАТ-32 означает, что номера блоков 
теперь 32-разрядные, поэтому для хранения старших разрядов номера начального 
блока файла требуются дополнительные 16 бит. 

Теперь мы подходим к сердцу файловой системы \Уіпс1о\Ѵ8 98: способу представ¬ 
ления длинных имен файлов, обладающему обратной совместимостью с МЗ-БОЗ. 
Выбранное решение заключается в назначении каждому файлу двух имен: (потен¬ 
циально) длинного имени файла (в формате ІАнсосІе, для совместимости с \Ѵіп- 
с1о\ѵз ТГГ) и имени формата 8 + 3 для совместимости с МЗ-ЭОЗ. Доступ к файлам 
может быть получен по любому имени. Когда создается файл, имя которого не 
удовлетворяет правилам МЗ-БОЗ (8 символов для имени и 3 символа для расши¬ 
рения, ограниченный набор символов, отсутствие пробелов и т. д.), \ѴіпсІо\ѵ5 98 
создает дополнительное имя формата МЗ-ЭОЗ в соответствии с определенным 
алгоритмом. Берутся первые шесть символов имени, преобразуются при необхо¬ 
димости в верхний регистр А5СІІ, после чего к ним добавляется суффикс -1. Если 
такое имя уже есть, то используется суффикс -2 и т. д. Кроме того, удаляются 
Пробелы и лишние точки, а определенные символы преобразуются в символы под¬ 
черкивания. Нанример, имя файла Тке ііте ка$ соте іке шаігив ваиТ получает имя 
формата МЗ-ЭОЗ ТНЕТІМ- 1. Если впоследствии создается файл с именем Тке Ііте 
кав соте іке гаЬЫі ваЫ, ему назначается имя ТНЕТІМ-2 и т. д. 


«Тюлень сказал: „Пришла пора..."». Строка из книги Льюиса Кэрролла «Алиса в Зазеркалье». — 
Примеч. перев. 
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Имя формата М5-И05 хранится в каталоге прямо в описателе, показанном на 
рис. 6.30. Если у файла есть также длинное имя, оно хранится в одной или несколь¬ 
ких каталоговых записях, предшествующих описателю файла с именем в формате 
М8-И05. Каждая такая запись содержит до 13 символов формата Ипісосіе. Эле¬ 
менты имени хранятся в обратном порядке, начинаясь сразу перед описателем 
файла в формате М8-И08 и последующими фрагментами перед ним. Формат каж¬ 
дого фрагмента длинного имени показан на рис. 6.31. 

1 10 111 12 2 4 

5 символов 0 6 символов 0 2 символа 

\ 7 ] 

Последовательность / 

Атрибуты 

Контрольная 

сумма 

Рис. 6.31 . Формат каталоговой записи с фрагментом длинного имени файла в ѴѴІпсІоѵ/з 98 

Возникает очевидный вопрос: «Как файловая система \ѴіпсІо\ѵ5 98 отличает 
каталоговые записи, содержащие имя файла в формате М8-Э08, от фрагментов 
длинных имен?» Ответ содержится в поле АйгіЪиіев (атрибуты). Для фрагмента 
длинного имени это поле содержит значение ОхОР, что соответствует невозмож¬ 
ной комбинации атрибутов для описателя файла в М8-Э08. Старые программы, 
написанные для работы в М8-008, читая каталог, просто игнорируют такие описа¬ 
тели как неверные. Порядок фрагментов имени учитывается в первом байте ката¬ 
логовой записи. Последний фрагмент имени отмечается добавлением к порядково¬ 
му номеру числа 64. Поскольку для порядкового номера используется всего 6 бит, 
теоретически максимальная длина имени файла может составить 63 х 13 = 819 
символов. На практике она ограничена 260 символами по историческим причинам. 

Каждый фрагмент длинного имени содержит поле Скесквит (контрольная 
сумма) во избежание следующей проблемы. Сначала программа, работающая в си¬ 
стеме \Ѵіп(1о\ѵ5 98, создает файл с длинным именем. Затем компьютер перезагру¬ 
жается в М8-008 или \Ѵіпс1о\Ѵ5 3. После этого старая программа, удаляя файл, 
удаляет из каталога имя формата М8-008, но оставляет в нем предшествующее 
ему длинное имя (так как ей ничего не известно о длинных именах). Наконец, ка¬ 
кая-то программа создает новый файл, используя освободившееся место в катало¬ 
ге. К этому моменту мы имеем верную последовательность фрагментов длинно¬ 
го имени, предшествующую описателю файла формата М8-Н08, который не имеет 
к ней никакого отношения. Поле Скесквит позволяет системе \ѴіпсІо\ѵ5 98 обнару¬ 
жить такую ситуацию. Конечно, поскольку для поля СНесквитп используется всего 
один байт, есть один шанс из 256, что \Ѵіпс1о\ѵз 98 не заметит подмены. 

Рассмотрим пример использования длинного имени файла на рис. 6.32. В данном 
случае файл назван Тке уиіск Ьгоыт /ох/итрв оѵегіке Іагу (Іо§ 1 . Поскольку в этом 
имени 42 символа, то оно определенно квалифицируется как длинное. Имя формата 
М8-008, созданное из него, выглядит как ТНЕ0УІ~ 1 и хранится в последней записи. 

1 Незаконченная любимая фраза программистов, содержащая все символы английского алфавита. 

Полностью фраза выглядит так: *Тке диіск Ьгоиіп /ох}итр$ оѵег (Не Іагу сіо^’в іаіі». — Примеч. перво. 
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Рис. 6.32. Пример хранения длинного имени файла в ѴѴІпсІоѵѵз 98 

Каталоговая структура обладает некоторой избыточностью, позволяющей об¬ 
наруживать проблемы, вызванные вмешательством старых программ, написанных 
для работы в \ѴіпсІо\ѵ5 3. Порядковый номер в начале каждого фрагмента длинно¬ 
го имени не так уж и нужен, так как бит 0x40 помечает первый фрагмент, но он 
обеспечивает дополнительную избыточность. Кроме того, поле Ьохю на рис. 6.32 
(младшая половина номера начального кластера) равно 0 во всех фрагментах, кро¬ 
ме последнего, что также позволяет избежать неверной интерпретации этих ката- 
логовых записей старыми программами и разрушения файловой системы. Байт ЫТ 
используется системой \Ѵіпс1о\ѵх ЫТ и игнорируется системой \УіпсІо\ѵх 98. Байт А 
содержит атрибуты файла. 

Реализация файловой системы РАТ-32 концептуально близка к реализации 
файловой системы РАТ-16. Однако вместо массива из 65 536 элементов в ней ис¬ 
пользуется столько, сколько нужно, чтобы покрыть весь раздел диска. Если диск 
содержит миллион блоков, то и таблица будет состоять из миллиона элементов. 
Для экономии памяти система \Ѵйкіо\ѵ5 98 не хранит их все сразу в памяти, а ис¬ 
пользует окно, накладываемое на таблицу. 


Файловая система ІИЧІХѴ7 

Даже в ранних версиях системы ІЖІХ применялась довольно сложная много¬ 
пользовательская файловая система, так как в основе этой системы лежала опера¬ 
ционная система МІЛЛЛСЗ. Ниже будет рассмотрена файловая система Ѵ7, раз¬ 
работанная для компьютера РЭР-П, сделавшего систему ІЖІХ знаменитой. 
Современные версии будут обсуждаться в главе 10. 

Файловая система представляет собой дерево, начинающееся в корневом ката¬ 
логе, с добавлением связей, формирующих направленный ациклический граф. Име¬ 
на файлов могут содержать до 14 символов, включающих в себя любые символы 
АЗСП, кроме косой черты (использовавшейся в качестве разделителя компонентов 
пути) и символа N111. (использовавшегося для дополнения имен короче 14 сим¬ 
волов). Символ N111. обозначается байтом 0. 

Каталог ІЖІХ содержит по одной записи для каждого файла этого каталога. 
Каждая каталоговая запись максимально проста, так как в системе ІЖІХ ис¬ 
пользуется схема і-узлов (см. рис. 6.12). Каталоговая запись состоит всего из двух 
полей: имени файла (14 байт) и номера і-узла для этого файла (2 байт), как пока- 



494 


Глава 6. Файловые системы 


зано на рис. 6.33. Эти параметры ограничивают количество файлов в файловой 
системе числом 64 К. 


Байты 2 14 


Имя файла 


Номер 

і-узла 

Рис. 6.33. Каталоговая запись файловой системы ІЛЧІХ Ѵ7 

Как и і-узлы на рис. 6.12, і-узлы системы ІЖІХ содержат некоторые атрибуты. 
К этим атрибутам относятся такие параметры, как размер файла, три указателя 
времени (создания, последнего доступа и последнего изменения), идентификатор 
владельца, номер группы, информация о защите и счетчик каталоговых записей, 
указывающих на этот і-узел. Последнее поле необходимо для связей. При добавле¬ 
нии новой связи к і-узлу счетчик в і-узле увеличивается на единицу. При удалении 
связи счетчик в і-узле уменьшается на единицу. Когда значение счетчика достига¬ 
ет нуля, і-узел освобождается, а блоки диска, которые занимал файл, возвращают¬ 
ся в список свободных блоков. 

Для учета дисковых блоков файла используется обобщение схемы, показанной 
на рис. 6.12, позволяющее работать с очень большими файлами. Первые 10 диско¬ 
вых адресов хранятся в самом і-узле. Таким образом, для небольших файлов вся 
необходимая информация содержится прямо в і-узле, считываемом с диска при 
открытии файла. Для файлов большего размера один из адресов в і-узле представ¬ 
ляет собой адрес блока диска, называемого одинарным косвенным блоком. Этот 
блок содержит дополнительные дисковые адреса. Если и этого недостаточно, 
используется другой адрес в і-узле, называемый двойным косвенным блоком, 
и содержащий адрес блока, в котором хранятся адреса однократных косвенных 
блоков. Если и этого мало, используется тройной косвенный блок. Полная схема 
показана на рис. 6.34. 

При открытии файла файловая система по имени файла находит его блоки на 
диске. Рассмотрим на примере открытие файла /изг/азІ/тЬох. В качестве примера 
будем использовать файловую систему ІЖІХ, хотя основы алгоритма одинаковы 
для всех иерархических каталоговых систем. Сначала файловая система открыва¬ 
ет корневой каталог. В системе ІЖІХ его і-узел располагается в фиксированном 
месте диска. По этому і-узлу система определяет положение корневого каталога, 
который может находиться в любом месте диска, в данном примере — в блоке 1. 

Затем файловая система считывает корневой каталог и ищет в нем первый компо¬ 
нент пути, изг, чтобы определить номер і-узла файла /изг. Определить местоположе¬ 
ние і-узла несложно, так как для каждого из них предусмотрено фиксированное 
место на диске. По этому і-узлу файловая система находит каталог /изг и находит 
в нем следующий компонент, азі. Найдя описатель азі, файловая система получает 
і-узел для каталога /изг /азі. По этому і-узлу она получает доступ к самому каталогу, 
в котором ищет файл тЬох. При этом і-узел файла тЬох считывается в память и оста¬ 
ется там, пока файл не будет закрыт. Процесс поиска проиллюстрирован на рис. 6.35. 
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Рис. 6.34.1-узел файловой системы ІЛЧІХ Ѵ7 
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Рис. 6.35. Этапы поиска файла /изг/азІ/тЬох 


Относительные пути файлов обрабатываются так же, как и абсолютные, с той 
разницей, что алгоритм начинает работу не с корневого, а с рабочего каталога. 
В каждом каталоге есть элементы «.» и «..», помещаемые в каталог в момент его 
создания. Элемент «.» содержит номер і-узла текущего каталога, а элемент «..» — 
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номер і-узла родительского каталога. Таким образом, процедура, ищущая файл 
,./сІіск/рго[*.с, просто находит «..» в рабочем каталоге, разыскивает в нем номер 
і-узла родительского каталога, в котором ищет описатель каталога (Иск. Для обра¬ 
ботки этих имен не требуется специального механизма. Имена рабочего и родитель¬ 
ского каталогов представляют собой обычные АЗСП-строки, не отличающиеся от 
любых других имен. 


Исследования в области файловых систем 

Файловым системам всегда уделялось больше внимания исследователей, чем дру¬ 
гим частям операционной системы, и такая ситуация сохраняется до сих пор. Не¬ 
которые подобные исследования касаются структуры файловой системы. Послед¬ 
нее время популярными являются файловые системы с журнальной структурой 
ЬР5 [226, 356]. Логический диск разбивает файловую систему на два уровня: фай¬ 
ловую систему и дисковую систему [85]. Построение файловой системы из нара¬ 
щиваемых уровней также составляет тему исследований [152]. 

Расширяемые файловые системы аналогичны расширяемым ядрам, рассматри¬ 
вавшимся в главе 1. Они позволяют добавлять к файловым системам новые воз¬ 
можности без необходимости пересоздавать их с нуля [174, 180]. 

Другой популярной темой исследований являются измерения состава и ис¬ 
пользования файловой системы. Исследователи измеряют такие факторы, как рас¬ 
пределение размеров файлов, время жизни файлов, частоту обращений к файлам, 
соотношение частот операций чтения и записи и многие другие параметры [98,128, 
281,346]. 

Другие исследователи занимались вопросами производительности файловой 
системы и способами улучшения опережающего чтения, кэширования, снижения 
количества операций копирования и т. д. Как правило, эти исследователи произ¬ 
водят измерения, определяют, где находятся узкие места, удаляют, по меньшей 
мере, одно из них, после чего снова производят измерения на улучшенной систе¬ 
ме, чтобы проверить свои результаты [52, 256, 260]. 

Архивация и восстановление файловой системы представляет собой тему, о ко¬ 
торой многие пользователи редко задумываются до тех пор, пока не случится что- 
либо страшное. В этой области также появляются новые идеи оптимизации [62, 
94,160]. С этой темой связан вопрос о том, что делать, когда пользователь удаляет 
файл — удалить его или скрыть? Например, файловая система ЕІерЬапГ никогда 
ничего не забывает [290, 291]. 


Резюме 

При взгляде снаружи файловая система представляет собой набор файлов и ката¬ 
логов плюс операции с ними. Файлы могут считываться и записываться, каталоги 
могут создаваться и удаляться. Файлы могут перемещаться из одного каталога в дру¬ 
гой. В большинстве современных файловых систем поддерживается иерархичес¬ 
кая каталоговая система, в которой каталоги могут содержать подкаталоги, кото¬ 
рые, в свою очередь, также могут иметь подподкаталоги и т. д. До бесконечности. 
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При взгляде изнутри файловая система выглядит совсем по-другому. Разработ¬ 
чикам файловых систем приходится заботиться о том, как файлам выделяется ме¬ 
сто на диске, и о том, как система следит за тем, какой блок какому файлу принад¬ 
лежит. Различные варианты реализации файлов включают в себя непрерывные 
файлы, связные списки, таблицы размещения файлов и і-узлы. В различных сис¬ 
темах используются различные каталоговые структуры. Атрибуты файла могут 
храниться прямо в каталоге или в другом месте (например, в і-узле). Учет диско¬ 
вого пространства может осуществляться с помощью списков свободных блоков 
или битовых массивов. Надежность файловых систем может быть увеличена при 
помощи создания инкрементных резервных копий, а также с помощью програм¬ 
мы, способной исправлять поврежденные файловые системы. Производительность 
файловых систем также является важным вопросом. Она может быть увеличена 
различными способами, включая кэширование, опережающее чтение и размеще¬ 
ние блоков файла рядом друг с другом. Файловые системы с журнальной структу¬ 
рой тоже увеличивают производительность, выполняя операции записи больши¬ 
ми блоками данных. 

Файловые системы описаны на примере 15 0 9660, СР/М, М5-Э05, \Ѵіпсіо\ѵ5 98 
и ІШІХ. Они во многом отличаются друг от друга, в частности способом учета при¬ 
надлежности блоков файлам, каталоговой структурой и управлением свободным 
дисковым пространством. 


Вопросы 

1. Создайте пять различных путей к файлу /е(с/ра$$ихІ. Подсказка : используй¬ 
те элементы каталога «> и «..». 

2. В системе \Ѵітіс1о\ѵя, когда пользователь дважды щелкает мышью на файле, 
отображаемом в программе \Ѵітісіочѵя Ехріогег, запускается программа, ко¬ 
торой в качестве параметра передается имя этого файла. Перечислите два 
различных способа указания операционной системе, какую программу сле¬ 
дует запускать при двойном щелчке мышью. 

3. В ранних версиях системы ІШІХ исполняемые файлы (файлы а.оиі) начи¬ 
нались со специфического «магического» числа, не являвшегося случайным. 
Эти файлы начинались с заголовка, за которым следовали сегменты с тек¬ 
стом программы и данными. Как вы думаете, почему для исполняемых фай¬ 
лов было выбрано особенное «магическое» число, тогда как для файлов дру¬ 
гих типов использовались более или менее случайные «магические» числа 
в качестве первого слова? 

4. В табл. 6.2 один из атрибутов представляет собой длину записи. Зачем этот 
атрибут нужен операционной системе? 

5. Является ли необходимым системный вызов ореп в системе ІШІХ? Какими 
будут последствия его отсутствия? 

6. В системах, поддерживающих последовательный доступ, всегда имеется 
операция для перемотки файлов. Нужна ли такая операция в системах, под¬ 
держивающих файлы произвольного доступа? 
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7. В некоторых операционных системах предоставляется системный вызов 
гепагае, позволяющий сменить имя файла. Есть ли разница между использо¬ 
ванием этого системного вызова и копирования файла с новым именем с 
последующим удалением старого файла? 

8. Некоторые системы позволяют отображать часть файла на память. Какие 
ограничения должны быть наложены на такую систему? Как реализуется 
такое частичное отображение файла на память? 

9. Простая операционная система поддерживает только один каталог, но по¬ 
зволяет хранить в нем произвольное количество файлов с именами произ¬ 
вольной длины. Можно ли на такой системе симулировать иерархическую 
файловую систему? Как? 

10. В системах ІШІХ и \Ѵіпс1о\ѵ5 произвольный доступ к файлу осуществляет¬ 
ся при помощи специального системного вызова, перемещающего указатель 
текущей позиции в файле на новое место. Предложите альтернативный ме¬ 
тод реализации произвольного доступа без использования этого системно¬ 
го вызова. 

11. Рассмотрите дерево каталогов на рис. 6.7. Если /и$г/]іт является рабочим 
каталогом, как будет выглядеть абсолютный путь для файла с относитель¬ 
ным путем ,./а$(/х ? 

12. Как указывалось в тексте, работа с непрерывными файлами приводит к фраг¬ 
ментации диска, так как теряется некоторая часть дискового пространства 
в последних блоках файлов, чья длина не кратна целому числу блоков. 
Является эта фрагментация внутренней или внешней? Приведите аналогию 
с вопросом, обсуждавшимся в предыдущей главе. 

13. Один из способов использовать непрерывные файлы на диске и не страдать 
от дыр состоит в уплотнении диска при каждом удаленном файле. Посколь¬ 
ку все файлы являются непрерывными, для копирования файла требуется 
определенное время на поиск цилиндра и вращение диска при считывании 
файла, после которого происходит перенос данных на полной скорости. При 
записи файла на диск требуются аналогичные операции. При времени по¬ 
иска цилиндра, равном 5 мс, задержке вращения в 4 мс, скорости передачи 
данных 8 Мбайт/с и среднем размере файла 8 Кбайт, сколько понадобится 
времени для того, чтобы прочитать файл в оперативную память, а затем за¬ 
писать его обратно на новое место на диске? При тех же параметрах сколько 
потребуется времени для уплотнения половины 16-гигабайтного диска? 

14. В свете ответа на предыдущий вопрос, есть ли вообще смысл в уплотнении 
диска? 

15. Некоторым цифровым потребительским устройствам требуется хранить дан¬ 
ные, например, в виде файлов. Назовите современное устройство, для которо¬ 
го хранение данных в виде непрерывных файлов является прекрасной идеей. 

16. Как реализован произвольный доступ к файлам в М5-005? 

17. Рассмотрите і-узел, изображенный на рис. 6.12. Если он содержит 10 дисковых 
адресов, по 4 байт каждый, а все дисковые блоки имеют размер 1024 байт, 
чему равен максимальный размер файла? 
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18. Было предложено увеличить производительность и эффективность исполь¬ 
зования дискового пространства при помощи хранения коротких файлов 
прямо в і-узлах. Исходя из рис. 6.12, сколько данных может храниться внут¬ 
ри і-узла? 

19. Две студентки с факультета кибернетики, Кэролин и Элинор, обсуждают 
і-узлы. Кэролин утверждает, что память стала такой большой и дешевой, что 
при открытии файла проще и быстрее считать новую копию і-узла в таблицу 
і-узлов, чем искать этот і-узел по всей таблице. Элинор не согласна. Кто прав? 

20. Назовите одно преимущество жестких связей над символьными связями 
и одно преимущество символьных связей над жесткими связями. 

21. Учет свободного дискового пространства может осуществляться с помощью 
связных списков или битовых массивов. Дисковые адреса состоят из В бит. 
При каком условии для диска из В блоков, Р из которых свободны, список 
займет меньше места, чем битовый массив? Выразите ваш ответ в процен¬ 
тах от объема диска для В = 16. 

22. После первого форматирования дискового раздела начало битового масси¬ 
ва учета свободных блоков выглядит так: 1000 0000 0000 0000 (первый блок 
используется для корневого каталога). Система всегда ищет свободные бло¬ 
ки от начала раздела, поэтому после записи файла Л, занимающего 6 бло¬ 
ков, битовый массив принимает следующий вид: 1111 1110 0000 0000. По¬ 
кажите, как будет выглядеть битовый массив после каждой из следующих 
действий: 

а) записывается файл В размером в 5 блоков; 

б) удаляется файл А; 

в) записывается файл С размером в 8 блоков; 

г) удаляется файл В. 

23. Что произойдет, если битовый массив или список свободных блоков ока¬ 
жется полностью потерян в результате сбоя? Есть ли способ восстановле¬ 
ния от такого сбоя или с диском можно попрощаться? Обсудите свой ответ 
отдельно для файловых систем ІЖІХ и РАТ-16. 

24. Ночная работа Оливера Аула в университете состоит в смене лент, исполь¬ 
зуемых для архивации данных. Ожидая окончания записи на каждую лен¬ 
ту, Оливер пишет статью, в которой доказывает, что пьесы Шекспира были 
написаны инопланетными пришельцами. За неимением другой системы, его 
текстовый процессор работает прямо в архивируемой системе. Есть ли ка¬ 
кие-либо проблемы, связанные с подобной организацией? 

25. В главе обсуждалась тема создания инкрементных резервных копий. В сис¬ 
теме \Ѵілс1о\ѵ5 легко определить, какой файл следует архивировать, так как 
у каждого файла имеется специальный архивный бит. В системе ІЖІХ та¬ 
кого бита нет. Как программа архивации в системе ІЖІХ определяет, для 
какого файла следует создать резервную копию? 

26. Допустим, что файл 21 на рис. 6.21 не был изменен с момента последней архи¬ 
вации. Как будут при этом отличаться четыре битовых массива на рис. 6.22? 
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27. Было предложено хранить первую часть каждого файла системы ІЖІХ в том 
же дисковом блоке, что и его і-узел. Каковы преимущества такого подхода? 

28. Рассмотрим рис. 6.23. Возможна ли ситуация, при которой для некоего бло¬ 
ка значение счетчиков в обоих списках равно 2? Как может быть исправле¬ 
на эта проблема? 

29. Производительность файловой системы зависит от процента блоков, кото¬ 
рые удается в нем найти. Напишите формулу для среднего времени удов¬ 
летворения запроса блока при частоте успешных обращений, равной к, если 
удовлетворение запроса из кэша занимает 1 мс, а для считывания блока с 
диска требуется 40 мс. Нарисуйте график этой зависимости для значений к 
в интервале от 0 до 1,0. 

30. У гибкого диска 40 цилиндров. Операция поиска занимает 6 мс на цилиндр. 
Если не пытаться разместить блоки файла близко друг к другу, два логичес¬ 
ки последовательных блока (то есть следующих один за другим в файле) 
окажутся в среднем на расстоянии 13 цилиндров друг от друга. Однако если 
операционная система пытается объединять логически соседние блоки в кла¬ 
стеры, то среднее межблоковое расстояние может быть уменьшено (напри¬ 
мер) до двух цилиндров. Сколько понадобится времени в обоих случаях 
для считывания 100-блочного файла, если задержка вращения составляет 
100 мс, а время переноса одного блока равно 25 мс? 

31. Рассмотрите идею графика на рис. 6.17, но для диска со средним временем 
поискав мс, скоростью вращения 15 000 об/мин и 262 144 байт на дорожке. 
Чему равна скорость передачи данных для блоков размера 1, 2 и 4 Кбайт? 

32. Некая файловая система использует 2-килобайтные дисковые блоки. Меди¬ 
анный размер файлов составляет 1 Кбайт. Если бы все файлы имели размер 
в 1 Кбайт, какая часть диска терялась бы понапрасну? Как вы думаете, по¬ 
тери в реальной системе выше этого числа или ниже? Поясните свой ответ. 

33. Система СР/М разрабатывалась для работы на маленьком гибком диске в 
качестве основного устройства хранения данных. Предположим, ее следует 
перенести на современный компьютер с большим жестким диском. Чему 
равен максимальный размер жесткого диска, при котором не потребуются 
изменения формата каталога, показанного на рис. 6.28? Поля в каталоге и 
другие системные параметры могут быть при необходимости изменены. Ка¬ 
кие изменения вы бы сделали? 

34. Таблица ЕАТ-16 системы М8-008 содержит 64 К элементов. Предполо¬ 
жим, что один бит потребовался для других целей и что таблица вместо 64 К 
содержит 32 768 элементов. Чему в этих условиях будет равен максималь¬ 
ный размер файла при отсутствии других изменений? 

35. В системе М8-В08 файлам приходится соревноваться за место в таблице 
ЕАТ-16, хранящейся в оперативной памяти. Если один файл использует 
к элементов, то есть к элементов, недоступных другим файлам, какие огра¬ 
ничения это накладывает на общую длину всех вместе взятых файлов? 
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36. В файловой системе ІШІХ килобайтные блоки и 4-байтовые дисковые ад¬ 
реса. Чему равен максимальный размер файла, если і-узел содержит 10 пря¬ 
мых адресов и по одному одинарному, двойному и тройному косвенному 
элементу? 

37. Сколько понадобится дисковых операций для считывания і-узла файла 
/шг/а$і/соиг$е5/о5/кап(Іои1.11 Предположим, что і-узел корневого каталога 
находится в оперативной памяти, но больше ничего, относящегося к этому 
пути, в памяти нет. Кроме того, предположите, что все каталоги занимают 
по одному блоку диска. 

38. Во многих версиях системы ІШІХ і-узлы хранятся в начале диска. Альтер¬ 
нативный дизайн заключается в выделении і-узлу блока в момент создания 
файла и помещении этого блока в начале первого блока файла. Обсудите 
преимущества и недостатки обоих подходов. 

39. Напишите программу, изменяющую порядок байтов в файле, так что по¬ 
следний байт становится первым, и наоборот. Программа должна работать 
с файлами произвольной длины, однако постарайтесь сделать программу до¬ 
статочно эффективной. 

40. Напишите программу, начинающую работу в заданном каталоге и спускаю¬ 
щуюся по дереву каталогов, записывая по пути размеры всех встретивших¬ 
ся ей файлов. Закончив сканирование каталога, программа должна распеча¬ 
тать гистограмму размеров файлов, используя шаг гистограммы в качестве 
параметра (например, при шаге 1024, файлы размером от 0 до 1023 байт 
попадают в один интервал, от 1024 до 2047 байт — в следующий интервал 
и т. д.). 

41. Напишите программу, сканирующую все каталоги файловой системы ІШІХ 
и находящую все і-узлы с двумя и более жесткими связями. Для каждого 
такого файла программа должна печатать список всех имен файлов, указы¬ 
вающих на этот файл. 

42. Напишите новую версию программы к для системы ІШІХ. Эта версия долж¬ 
на принимать в качестве параметра одно или несколько имен каталогов 
и для каждого каталога выдавать список всех файлов, содержащихся в этом 
каталоге, по одной строке на файл. Каждое поле должно форматироваться 
в соответствии с его типом. Укажите в списке только первый дисковый адрес 
или не указывайте никаких. 

43. Напишите файловую систему СР/М на языке С или С++. Необходимую для 
этого информацию вы можете найти в Интернете. 
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В последнее время все более широкое распространение получают такие компь¬ 
ютерные приложения, как цифровые фильмы, видеоклипы и музыка. Аудио- и 
видеофайлы могут храниться на диске и воспроизводиться по требованию. Ха¬ 
рактеристики этой цифровой информации сильно отличаются от характерис¬ 
тик традиционных текстовых файлов, для работы с которыми создавались совре¬ 
менные файловые системы. Для управления новыми типами данных требуются 
новые файловые системы. Кроме того, сохранение и воспроизведение аудио и 
видео накладывает новые требования на планировщик и другие части операци¬ 
онной системы. В следующих разделах мы изучим многие из этих вопросов и их 
влияние на устройство операционных систем, созданных для управления муль¬ 
тимедиа. 

Как правило, цифровые фильмы называют мультимедиа, что буквально озна¬ 
чает «более чем один носитель информации». Если следовать этому определению, 
то данная книга также является мультимедийным трудом, так как содержит ин¬ 
формацию двух различных типов: текст и изображения (рисунки). Но большин¬ 
ство людей обычно употребляют это слово, имея в виду документ, содержащий 
средства информации, протяженные во времени, то есть проигрываемые в тече¬ 
ние определенного интервала времени. В данной книге мы будем использовать это 
слово именно в таком значении. 

Другой неоднозначный термин — это «видео». Технически это просто гра¬ 
фическая составляющая фильма (в противоположность звуковой составляющей). 
В самом деле, у видеокамер и телевизоров часто есть два разъема, один из которых 
помечен словом «видео», а другой — «аудио», поскольку эти два сигнала разделе¬ 
ны. Однако термин «цифровое видео» обычно относится к полному продукту, со¬ 
держащему как изображение, так и звук. Ниже для обозначения полного продукта 
будет использоваться термин «фильм». Обратите внимание, что термин «фильм», 
употребляемый в этом смысле, не обязан быть двухчасовой лентой, снятой на 
студии в Голливуде за цену, превышающую стоимость Боинга 747. 30-секундный 
клип новостей, загружаемый по Интернету с домашней \ѵеЬ-страницы СЫН, так¬ 
же является фильмом в нашем определении. Говоря об очень коротких фильмах, 
мы будем употреблять и термин «видеоклип». 
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Введение в мультимедиа 

Прежде чем перейти к обсуждению технологии мультимедиа, следует сказать не¬ 
сколько слов о его сегодняшнем состоянии и перспективах с точки зрения пользо¬ 
вателя. На одиночном компьютере мультимедиа часто означает воспроизведение 
ранее записанного фильма с БѴБ (БіфЫ ѴегзаНІе Бізк — универсальный циф¬ 
ровой диск). БѴБ представляют собой оптические диски, для производства кото¬ 
рых используются те же самые поликарбонатные (пластиковые) диски диаметром 
120 мм, что и для производства СБ-КОМ, но информация записывается на них 
с большей плотностью. Емкость БѴБ составляет от 5 до 17 Гбайт, в зависимости 
от формата. 

Другой вариант использования мультимедиа заключается в загрузке видеокли¬ 
па из Интернета. Многие лѵеЬ-страницы содержат ссылки для загрузки коротких 
фильмов. На скорости 56 кбит/с загрузка даже короткого видеоклипа занимает 
довольно долгое время, однако с появлением более совершенных технологий 
передачи данных, таких как кабельное телевидение и АБ5Б (Азушшеігіс Біфіаі 
ЗиЬзсгіЬег Біпе — асимметричная цифровая абонентская линия), видеоклипов 
в Интернете становится все больше. 

Еще одна область, в которой мультимедийные средства должны поддержи¬ 
ваться, — это создание самих видеофильмов. Существуют различные системы 
редактирования мультимедиа, для более высокой производительности которых 
требуются специальные операционные системы, поддерживающие мультимедиа 
помимо традиционных задач. 

Все более важное положение мультимедиа занимает в компьютерных играх. 
В играх часто проигрываются небольшие видеоклипы, иллюстрирующие некото¬ 
рые события. Эти клипы, как правило, короткие, но в игре их содержится большое 
количество, и нужный клип выбирается динамически, в зависимости от действия 
пользователя. Сложность таких клипов возрастает с каждым годом. 

Наконец, наиболее интересной областью применения мультимедиа являет¬ 
ся видео по заказу, под которым подразумевается возможность для абонента 
не выходя из дома выбрать фильм для просмотра на своем телевизоре и тут же 
начать его просмотр. Для реализации видео по заказу требуется специальная ин¬ 
фраструктура. На рис. 7.1 показаны два возможных варианта инфраструктуры 
видео по заказу. Каждая инфраструктура состоит из одного или нескольких 
видеосерверов, распределительной сети и телевизионных приставок в каждом 
доме для декодирования сигнала. Видеосервер представляет собой мощный 
компьютер, хранящий в своей файловой системе большое количество фильмов и 
воспроизводящий их по требованию. Иногда в качестве видеосерверов использу¬ 
ются мэйнфреймы, так как подключить, скажем, 1000 больших дисков к мэйн¬ 
фрейму не составляет сложности, тогда как подключение 1000 дисков к персональ¬ 
ному компьютеру любого типа представляет собой серьезную проблему. Большая 
часть материала следующих разделов посвящена видеосерверам и их операци¬ 
онным системам. 
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Медная витая пара 


а 


Оптоволоконный 



Коаксиальный ТВ-кабель 


б 

Рис. 7.1. Видео по заказу с применением различных технологий местного распределения: 

АОЗЦа); кабельное телевидение (б) 

Распределительная сеть между пользователями и видеосервером должна быть 
способна передавать данные на высокой скорости в режиме реального времени. 
Устройство таких сетей интересно и сложно, но оно не вмещается в рамки этой 
книги. Мы более не будем упоминать о них, только отметим, что в этих сетях 
всегда используются оптоволоконные кабели от видеосервера до того места, где 
живут абоненты. В системах АГ)5Ь, предоставляемых телефонными компаниями, 
последний километр данные передаются по существующим витым парам телефон¬ 
ных линий. В системах кабельного телевидения, услуги которого предоставляют¬ 
ся операторами кабельной связи, для локального распределения используются 
существующие телевизионные кабели. Преимущество системы АБЗЬ заключает¬ 
ся в том, что каждому пользователю предоставляется выделенный канал с гаран¬ 
тированной пропускной способностью. Недостатком является низкая пропускная 
способность (несколько мегабит в секунду), что вызвано ограничениями существу- 
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ющих телефонных линий. Кабельное телевидение использует высокоскоростные 
коаксиальные кабели (гигабиты в секунду), однако нескольким пользователям 
приходится совместно использовать один кабель, что приводит к состязанию за 
кабель и не гарантирует пропускной способности отдельному пользователю. 

Последний узел системы представляет собой телевизионную приставку, к ко¬ 
торой и присоединен АБЗЬ или телевизионный кабель. Это устройство является 
в действительности нормальным компьютером со специальными микросхемами 
для декодирования и декомпрессии видеопотока. Как минимум он содержит цен¬ 
тральный процессор, оперативную память, ПЗУ и интерфейс с системой АЭЗИ или 
телевизионным кабелем. 

Вместо телевизионной приставки фильм можно просматривать и на мониторе 
имеющегося у клиента персонального компьютера. В чем же причина внимания к 
телевизионным приставкам, хотя у большинства абонентов уже есть персональ¬ 
ные компьютеры? Операторы видео по заказу ожидают, что их клиенты захотят 
смотреть фильмы в гостиных, в которых обычно есть телевизор, но нет компьюте¬ 
ра. С технической точки зрения использование персонального компьютера вмес¬ 
то телевизионной приставки имеет гораздо больше смысла, так как компьютер 
обладает большими возможностями, у него есть диск большого объема и дисплей 
с гораздо более высоким разрешением. Мы часто будем использовать различие 
между видеосервером и клиентским процессом на стороне пользователя, занима¬ 
ющимся декодированием и отображением фильма. Однако с точки зрения кон¬ 
струкции системы почти не имеет значения, работает ли клиентский процесс на 
персональном компьютере или в телевизионной приставке. В настольной системе 
редактирования видеоизображения все процессы работают на одной и той же ма¬ 
шине, но мы будем продолжать использовать терминологию сервера и клиента, 
чтобы было ясно, что делает каждый процесс. 

Возвращаясь к мультимедиа, стоит отметить две ключевые характеристики, 
понимание которых необходимо для успешной работы: 

1. Мультимедиа использует предельно высокие скорости передачи данных. 

2. Для мультимедиа требуется воспроизведение в режиме реального времени. 

Высокие скорости передачи данных обусловлены природой визуальной и аку¬ 
стической информации. Человеческий глаз и ухо способны обрабатывать за секун¬ 
ду огромные объемы данных, поэтому им необходимо поставлять информацию с 
той скоростью, которая обеспечит приемлемый уровень качества восприятия. Ско¬ 
рости передачи данных некоторых цифровых источников мультимедиа и некото¬ 
рых распространенных устройств приведены в табл. 7.1. (Обратите внимание, что 
1 Мбит/с — это ІО 6 бит/с, но 1 Гбайт — это 2 30 байт.) Некоторые из этих форматов 
кодирования данных будут обсуждаться ниже в этой главе. Следует обратить 
внимание на высокую скорость передачи данных, требующуюся для мультимедиа, 
необходимость сжатия данных и на большие объемы, занимаемые данными. Напри¬ 
мер, несжатый 2-часовой фильм в формате НБТѴ (Ні§Ь БейпИлоп ТеІеѴізіоп — 
телевидение высокой четкости) занимает 570 Гбайт. Видеосерверу, хранящему 
1000 таких фильмов, нужно 570 Тбайт дискового пространства, что совсем нетри¬ 
виально с точки зрения современных стандартов. Также следует отметить, что при 
таких скоростях современная аппаратура не способна обходиться без сжатия дан¬ 
ных. Сжатие данных будет рассматриваться ниже в этой главе. 
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Таблица 7.1. Скорости передачи данных некоторых мультимедийных устройств 
и некоторых высокоскоростных устройств ввода-вывода 


Источник 

Мбит/с 

Гбайт/ч 

Устройство 

Мбит/с 

Телефон (кодово-импульсная 
модуляция) 

0,064 

0,03 

Быстрая сеть Еібегпеі 

100 

МРЗ музыка 

0,14 

0,06 

ЕЮЕ диск 

133 

Аудиокомпакт-диск 

1,4 

0,62 

Сеть АТМ ОС-3 

156 

МРЕО-2 фильм (640x480) 

4 

1,76 

5С5І ШгаѴѴІсІе диск 

320 

Цифровая видеокамера (720x480) 

25 

11 

ІЕЕЕ 1394 (РігеѴѴІге) 

400 

Несжатое телевидение(640x480) 

221 

97 

Гигабитная сеть Еібегпеі 

1000 

Несжатое НРТѴ (1280x720) 

648 

288 

5С5І Шга-160 диск 

1280 


Второе требование, накладываемое мультимедийными приложениями на систе¬ 
му, заключается в необходимости доставки данных в режиме реального времени. 
Графическая составляющая видеофильма состоит из последовательности кадров, 
передаваемых с определенной частотой. Система ІчГГЗС, используемая в Северной 
и Южной Америке и Японии, работает с частотой 30 кадров в секунду (точнее, 
29,97), тогда как в системах РАЬ и ВЕСАМ, используемых в остальном мире, при¬ 
меняется частота 25 кадров в секунду (25,00 для любителей точности). Кадры долж¬ 
ны доставляться через точные интервалы времени по 33,3 мс или по 40 мс соот¬ 
ветственно, чтобы изображение не подергивалось. 

Официально сокращение ИТЗС означает Наііопаі Теіеѵізіоп Зіапсіагсіз СоішпіІДее 
(Национальный комитет по телевизионным стандартам США), однако плохое ка¬ 
чество передачи цвета на ранних этапах существования телевидения привело к 
появлению шутки, согласно которой 1ФГЗС следует расшифровывать как «посто¬ 
янно меняющийся цвет» (Иеѵег Т\ѵісе (Фе Ваше Соіог). Аббревиатура РАЬ рас¬ 
шифровывается как РЬазе Аііегпаііоп Ьіпе (построчное изменение фазы). Техни¬ 
чески это лучшая из систем. Сокращение ВЕСАМ означает ЗЕдиепііеІ Соиіеиг 
Аѵес Метоіге (последовательные цвета с запоминанием). Эта система была раз¬ 
работана во Франции для защиты французских производителей телевизоров от 
иностранных конкурентов. Система ВЕСАМ также используется в восточной 
Европе; при появлении там телевидения тогдашние коммунистические правитель¬ 
ства не хотели допустить, чтобы их граждане смотрели немецкое (РАЬ) телевиде¬ 
ние, поэтому они выбрали несовместимую систему. 

Чувствительность человеческого уха превосходит чувствительность глаза, по¬ 
этому отклонение во времени доставки даже в несколько миллисекунд будет за¬ 
метным. Неравномерность времени доставки называется джиттером. Для обеспе¬ 
чения высокого качества воспроизведения следует удерживать джиттер в строгих 
рамках. Обратите внимание, что джиттер — это не то же самое, что задержка. Если 
распределительная сеть на рис. 7.1 задерживает при передаче все биты ровно на 
5000 с, фильм начнется несколько позже, но будет выглядеть прекрасно. С другой 
стороны, если задержка кадров будет случайной величиной в пределах от 100 до 
200 мс, видео будет выглядеть как старый фильм Чарли Чаплина, независимо от 
того, кто играет главные роли. 

Параметры реального времени, требуемые для приемлемого воспроизведения 
мультимедиа, часто называют параметрами качества обслуживания. К ним отно- 
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сят среднюю доступную пропускную способность, максимальную пропускную 
способность, минимальную и максимальную задержку (что вместе ограничивает 
джиттер) и вероятность потери бита. Например, сетевой оператор может предла¬ 
гать службу, гарантирующую среднюю пропускную способность, равную 4 Мбит/с, 
99 % задержек при передаче в интервале от 105 до 110 мс и частоту потерь битов, 
равную ІО -10 , что будет являться прекрасными параметрами для передачи фильма 
в формате МРЕС-2. Оператор может также предоставлять более дешевую, худше¬ 
го качества службу, со средней пропускной способностью в 1 Мбит/с (например, 
АБ5Б). В этом случае качество фильма придется каким-то образом снизить, ска¬ 
жем, снизив разрешение или частоту кадров, либо отбросив информацию о цвете 
и передавая фильм в черно-белом изображении. 

Наиболее простой способ обеспечения гарантированного качества службы 
заключается в предварительном резервировании мощностей для каждого нового 
клиента. Резервируемые ресурсы включают в себя часть времени центрального 
процессора, буферы памяти, пропускную способность диска и пропускную спо¬ 
собность сети. Если появляется новый клиент, желающий посмотреть фильм, но 
видеосервер (или сеть) вычисляет, что ему не хватит мощности для еще одного 
клиента, в этом случае видеосерверу придется отказать новому клиенту, чтобы не 
снижать качество обслуживания уже обслуживаемых клиентов. Таким образом, 
мультимедийным серверам требуется схема резервирования ресурсов и алгоритм 
управления допуском, принимающий решение о том, может ли сервер выполнить 
дополнительную работу. 


Мультимедийные файлы 

В большинстве систем обычный текстовый файл состоит из линейной последо¬ 
вательности байтов без какой-либо структуры, о которой знала бы операцион¬ 
ная система. В мультимедиа ситуация гораздо более сложная. Во-первых, видео- 
и аудиоданные полностью различны. Они вводятся совершенно разными устрой¬ 
ствами (ПЗС-матрицей или микрофоном), у них различная внутренняя структу¬ 
ра (видео передается с частотой 25—30 кадров в секунду, тогда как аудио обычно 
хранится в виде 44 100 отсчетов в секунду), и воспроизводятся они также различ¬ 
ными устройствами (монитором и громкоговорителями). 

Более того, большинство голливудских фильмов сегодня нацелено на всемирную 
аудиторию, немалая часть которой не говорит по-английски. Последняя проблема 
решается одним из двух способов. Для некоторых стран производится дополни¬ 
тельная звуковая дорожка, с голосами (но не звуковыми эффектами), дублирован¬ 
ными на местном языке. В Японии все телевизоры оснащены двумя звуковыми 
каналами, чтобы позволить зрителю слушать зарубежные фильмы на языке ори¬ 
гинала или на японском. Для выбора языка пульты дистанционного управления 
оснащаются специальной кнопкой. В других странах используется оригинальный 
звук с субтитрами на местном языке. 

Кроме того, многие телевизионные передачи сегодня снабжаются скрытыми 
субтитрами на английском, что позволяет англо-говорящим, но плохо слышащим 
людям смотреть эти передачи. В результате цифровой фильм может оказаться 
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состоящим из большого количества файлов: видеофайла, нескольких аудиофайлов 
и нескольких текстовых файлов с субтитрами на различных языках. ОѴО способны 
хранить до 32 звуковых дорожек на разных языках, а также файлы с субтитрами. 
Простой набор мультимедийных файлов проиллюстрирован на рис. 7.2. Значение 
файлов быстрой перемотки вперед и назад будет объяснено ниже в этой главе. 

Ргате 


Видео 


Английская 
звуковая дорожка 


1 2 3 4 5 6 7 8 


1 і 

і § 

1 ё 

1 у 

1 » 

1 і 

16 

ц 

л _X 

Л _I, 

і 1. 

-І _ 

^ X 

с Ж 

XI - 

_IX_ 



Французская 
звуковая дорожка 



Немецкая 
звуковая дорожка 



Английские 

субтитры 


Голландские 

субтитры 


Здравствуй, 

Боб 

Здравствуй, 

Алиса 

Хороший 

денек 

Это 

точно 

Как 

поживаешь? 

Отлично 

А ты? 

Хорошо 


Здравствуй, 

Боб 

Здравствуй, 

Алиса 

Хороший 

денек 

Это 

точно 

Квк 

поживаешь? 

Отлично 

Аты? 

Хорошо 



Рис. 7.2. Фильм может состоять из нескольких файлов 

Таким образом, файловая система должна следить за несколькими «субфайла¬ 
ми». Одна возможная схема заключается в том, что каждый субфайл хранится как 
обычный файл (например, при помощи і-узла, в котором хранятся номера всех его 
блоков), а все субфайлы описываются новой структурой. Другой способ состоит 
в создании новой разновидности двумерного і-узла, в котором в каждой колонке 
перечисляются блоки каждого субфайла. В общем, организация должна предо¬ 
ставлять зрителю возможность при просмотре фильма динамически выбирать 
звуковые дорожки и субтитры. 
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Во всех случаях необходим некий способ синхронизации субфайлов, чтобы 
любая звуковая дорожка соответствовала изображению. Если изображение и звук 
хотя бы слегка рассинхронизируются, зритель будет слышать слова актера до или 
после движения его губ, что легко определяется и довольно сильно раздражает 
зрителя. 

Для лучшего понимания организации мультимедийных файлов необходимо 
понимать, как работают цифровое аудио и видео. В следующем разделе мы позна¬ 
комимся с основами цифрового представления аудио- и видеосигналов. 

Кодирование звука 

Аудиоволна (звуковая волна) представляет собой одномерную акустическую вол¬ 
ну. Когда акустическая волна попадает в ухо человека, барабанная перепонка на¬ 
чинает вибрировать, вызывая вибрацию тонких костей среднего уха, в результате 
чего в мозг по нерву посылается пульсирующий сигнал. Эта пульсация восприни¬ 
мается слушателем как звук. Подобным образом, когда акустическая волна воз¬ 
действует на микрофон, микрофон формирует электрический сигнал, представля¬ 
ющий амплитуду звука в виде функции времени. 

Человеческое ухо слышит сигналы в диапазоне частот от 20 до 20 000 Гц, хотя 
некоторые животные, например собаки, могут слышать и более высокие частоты. 
Наше ухо слышит логарифмически, поэтому сила звука обычно измеряется в ло¬ 
гарифмах отношения амплитуд, например в децибелах (дБ): 

дБ = 20 1о§ю (А/В). 

Если принять нижний предел слышимости (давление около 0,0003 дин/см 2 , что 
равно Зх10~ 5 Па) для синусоидальной волны частотой в 1 кГц за 0 дБ, то громкос¬ 
ти обычного разговора будет соответствовать 50 дБ, а болевой порог наступит при 
силе звука около 120 дБ, что соответствует отношению амплитуд, равному одному 
миллиону. Чтобы избежать путаницы, А я В в формуле являются амплитудами. 
Если использовать вместо амплитуд уровни мощности, которые пропорциональ¬ 
ны квадратам амплитуд, следует в приведенной выше формуле вместо коэффици¬ 
ента 20 поставить число 10. 

Аудиоволны могут преобразовываться в цифровую форму при помощи анало¬ 
гово-цифрового преобразователя (АЦП). АЦП принимает на входе электричес¬ 
кое напряжение и формирует двоичное число на выходе. На рис. 7.3, а показан 
пример синусоидальной волны. Чтобы представить этот сигнал в цифровом виде, 
мы можем измерять значения сигнала (отсчеты) через равные интервалы времени, 
как показано на рис. 7.3, б. Если звуковая волна не является чисто синусоидальной, 
а представляет собой сумму нескольких синусоидальных волн, самая высокая час¬ 
тота составляющих которых равна /, тогда для последующего восстановления 
сигнала достаточно измерять значения сигнала с частотой дискретизации 2/. Это 
утверждение было математически доказано Найквистом в 1924 году. Производить 
измерения сигнала с большей частотой нет смысла, так как более высокие частоты 
отсутствуют в сигнале. 
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а б в 

Рис. 7.3. Синусоидальная волна (а); дискретизация синусоидальной волны (б); 
квантование отсчетов (а) 

Оцифрованные отсчеты никогда не бывают точными. Трехбитовые отсчеты на 
рис. 7.3 могут принимать только 8 значений, от -1,00 до +1,00 с шагом 0,25. При 
8-битовом квантовании каждый отсчет может принимать одно из 256 различных 
значений. При 16 битах на отсчет можно кодировать сигнал с еще более высокой 
точностью, так как каждому значению сигнала можно поставить в соответствие 
одно из 65 536 различных значений. Ошибка, возникающая в результате неточно¬ 
го соответствия квантованного сигнала исходному сигналу, называют шумом 
квантования. При недостаточном количестве битов, которыми представляется 
каждый отсчет сигнала, этот шум может быть настолько велик, что будет разли¬ 
чим на слух как искажение исходного сигнала или как посторонние шумы. 

Двумя хорошо известными примерами оцифрованного звука являются телефон 
(новые цифровые АТС) и аудиокомпакт-диски. В кодово-импульсной модуляции, 
применяемой для телефонной системы, используются 7-битовые (в Северной Аме¬ 
рике и Японии) и 8-битовые (в Европе) отсчеты, передаваемые 8000 раз в секунду. 
Таким образом, получаемая скорость передачи данных составляет 56 000 бит/с или 
64 000 бит/с. При частоте дискретизации в 8 кГц частотные составляющие сигна¬ 
ла выше 4 кГц теряются. 

Аудиокомпакт-диски содержат звуковой сигнал, оцифрованный с частотой 
дискретизации 44 100 Гц, в результате чего они могут хранить звуки с частотами 
до 22 кГц, что достаточно для людей, но плохо для собак. Каждому отсчету выде¬ 
ляется 16 бит, которые используются как обычное 2-байтовое целое число, про¬ 
порциональное амплитуде сигнала. Обратите внимание, что 16-битовый отсчет 
может принимать всего 65 536 различных значений (96 дБ), хотя динамический 
диапазон уха составляет около одного миллиона (120 дБ). Тем не менее этот фор¬ 
мат достаточно хорош, а во многих случаях даже избыточен. При 44 100 отсчетов 
в секунду по 16 бит каждый аудиокомпакт-диску нужны пропускная способность 
в 705,6 кбит/с для монофонического сигнала и 1,411 Мбит/с для стереофоничес¬ 
кого. Алгоритм МРЕС, уровень 3 (МРЗ) позволяет сжимать оцифрованный звук 
примерно в 10 раз. В последние годы стали популярными переносные плейеры, 
воспроизводящие музыку в этом формате. 

Цифровой звук легко обрабатывать на компьютере. Существуют десятки про¬ 
грамм для персональных компьютеров, позволяющие пользователям записывать, 
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воспроизводить, редактировать, микшировать и хранить звук. Сегодня вся профес¬ 
сиональная звукозапись и редактирование звука осуществляется в цифровом виде. 

Кодирование изображения 

Сетчатка глаза человека обладает инерционными свойствами, то есть яркое изоб¬ 
ражение, быстро появившееся на сетчатке, остается на ней несколько миллисе¬ 
кунд, прежде чем угаснуть. Если последовательность одинаковых или близких 
изображений появляются и исчезают с достаточно высокой частотой, то глаз чело¬ 
века не заметит, что он смотрит на дискретные изображения. Частота, при которой 
глаз перестает замечать мигание яркости источника света (изображения), состав¬ 
ляет около 50 Гц. Все видео (то есть телевизионные) системы используют этот 
принцип для создания двигающихся изображений. 

Чтобы понять, как работают видеосистемы, лучше всего начать с простого ста¬ 
ромодного черно-белого телевидения. Для преобразования двумерного изображе¬ 
ния в вид одномерной зависимости напряжения от времени камера быстро скани¬ 
рует электронным лучом изображение, разбивая его на горизонтальные линии и 
записывая по мере продвижения интенсивность света. Закончив сканирование 
кадра, луч возвращается в исходную точку. Путь сканирования, который прохо¬ 
дит электронный луч в передающей камере и принимающей телевизионной труб¬ 
ке, показан на рис. 7.4. В последнее время все большее распространение получают 
матричные жидкокристаллические мониторы и цифровые камеры с ПЗС-матри¬ 
цами (прибор с зарядовой связью). В этих устройствах нет электронно-лучевой 
трубки и сканирующего луча. 



Рис. 7.4. Путь сканирующего луча в видеосистеме N150 
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В разных странах приняты различные стандарты, описывающие параметры ска¬ 
нирования (количество строк развертки и т. д.). В системе ЫТ5С, принятой в Се¬ 
верной и Южной Америке, а также в Японии, экран разбивается на 525 гори¬ 
зонтальных линий развертки, соотношение горизонтального и вертикального 
размеров экрана составляет 4:3, кадры передаются с частотой 30 кадров в секунду. 
Принятая в Европе система РАЬ/5ЕСАМ разбивает кадр на 625 линий, размеры 
экрана у нее также 4:3, а частота кадров составляет 25 кадров в секунду. В обеих 
системах самые верхние и самые нижние линии кадра не показываются (это свя¬ 
зано с круглой формой электронно-лучевой трубки). На экране телевизоров пока¬ 
зываются только 483 из 525 линий развертки для системы ЫТ5С и 576 из 625 для 
системы РАЕ/5ЕСАМ. 

Хотя частоты в 25 кадров в секунду достаточно, чтобы передать плавное дви¬ 
жение, при такой частоте кадровой развертки многие зрители (особенно пожилые) 
заметят мигание изображения, связанное с тем, что сетчатка глаза успеет восста¬ 
новиться, прежде чем появится новый кадр. Увеличение частоты кадров потре¬ 
бовало бы увеличения объемов хранимой и передаваемой информации. Вместо 
этого было выбрано другое решение. Линии развертки показываются на экране 
телевизора не подряд, а через одну: сначала все нечетные, а затем все четные. Каж¬ 
дый такой полукадр называют полем. Эксперименты показали, что хотя люди за¬ 
мечают мерцание при 25 кадров в секунду, при 50 кадров в секунду оно уже не 
заметно. Такая техника называется чересстрочной разверткой. Телевидение или 
видеосистема, в которой не используется чересстрочная развертка, называется 
поступательным. 

В цветном видео используется тот же принцип развертки, что и в черно-белом, 
с той разницей, что вместо одного луча изображение представляется синхронно 
двигающимися тремя лучами: красным, зеленым и синим (КСВ — геф §гееп, Ыие). 
Комбинации этих трех цветов оказывается достаточно для передачи любого цвета 
благодаря особенностям устройства человеческого глаза. При передаче по каналу 
связи эти три цветовых сигнала объединяются в единый смешанный сигнал. 

Для совместимости с черно-белыми телевизионными приемниками во всех трех 
системах сигналы КОВ линейно объединяются в сумму этих сигналов, называе¬ 
мую яркостью, и два сигнала цветности. Однако в каждой из систем эти сигналы 
формируются с использованием различных коэффициентов. Экспериментально 
доказано, что человеческий глаз обладает гораздо более высокой чувствительнос¬ 
тью к изменению сигнала яркости, чем к изменению сигнала цветности. В резуль¬ 
тате сигнал цветности не обязательно кодировать так же точно, как и сигнал ярко¬ 
сти. Поэтому было решено передавать сигнал яркости в том же формате, что и 
черно-белый сигнал, а два узкополосных сигнала цветности передаются отдельно 
на более высокой частоте. Телевизоры обычно снабжаются регуляторами яркости 
и насыщенности цвета. Знакомство с сигналами яркости и цветности важно для 
понимания принципов действия алгоритмов видеосжатия. 

До сих пор мы рассматривали аналоговое видео. Обсудим теперь цифровое ви¬ 
део. Простейшая форма представления цифрового видео заключается в последо¬ 
вательности кадров, состоящих из прямоугольной сетки элементов рисунка, на¬ 
зываемых пикселами. В цветном телевидении достаточно использовать по 8 бит 
на каждый из трех цветов КСВ, что дает в сумме 24 бита на пиксел. Хотя числом, 
состоящим из 24 бит, можно обозначить около 16 млн цветовых оттенков, челове- 
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ческий глаз не в состоянии даже различить такое огромное количество цветовых 
оттенков, не говоря уже о больших количествах. 

Для гладкой передачи движения, как и в аналоговом видео, в цифровом видео 
необходимо отображать по меньшей мере 25 кадров в секунду. Однако, поскольку 
качественные мониторы обычно сами сканируют по нескольку раз хранящиеся 
в их памяти изображения с частотой 75 и более кадров в секунду, проблема мер¬ 
цания изображения решается па уровне монитора сама собой, и чередование строк 
в цифровом видео не требуется. 

Другими словами, плавность движущегося изображения определяется количе¬ 
ством отличающихся изображений в секунду, тогда как мерцание зависит от час¬ 
тоты перерисовки экрана. Не следует путать эти два параметра. Неподвижное 
изображение, рисуемое с частотой 20 кадров в секунду, не будет дергаться, но бу¬ 
дет мерцать, поскольку возбуждение сетчатки глаза успеет угаснуть, прежде чем 
появится следующий кадр. Фильм, в котором выводится 20 различных кадров 
в секунду, каждый из которых повторяется по четыре раза, не будет мерцать, но 
будет заметно отсутствие плавности движений. 

Важность этих двух параметров становится ясна, если мы попробуем оценить 
пропускную способность, необходимую для передачи цифрового видеосигнала по 
сети. Во всех современных компьютерных мониторах используется соотношение 
размеров экрана 4:3, поэтому они вполне могут использоваться для отображения 
телевизионного изображения. Стандартные используемые разрешения экрана 
составляют 640 х 480 (ѴСА), 800 х 600 (5ѴСА) и 1024 х 768 (ХСА). Для показа 
цифрового видео на ХСА-экране при 24 битах на пиксел и 25 кадрах в секунду 
потребуется поток данных со скоростью 472 Мбит/с. Даже канала ОС-9 будет 
недостаточно для этого, а прокладка такого кабеля в каждый дом пока еще не стоит 
на повестке дня. Удвоение частоты, чтобы избавиться от мерцания, выглядит еще 
менее привлекательно. Лучшее решение состоит в том, чтобы передавать 25 кад¬ 
ров в секунду и позволить компьютеру самому хранить эти кадры и отображать их 
с утроенной или учетверенной частотой. В обычном широковещательном телеви¬ 
дении такая стратегия почти не используется 1 , так как у обычных телевизоров нет 
памяти, кроме того, для хранения аналоговых сигналов в ОЗУ необходимо снача¬ 
ла преобразовать их в цифровую форму, что потребует дополнительного оборудо¬ 
вания. Таким образом, чередование строк применяется в обычном широковеща¬ 
тельном телевидении, но оно не нужно в цифровом видео. 


Сжатие видеоинформации 

Итак, теперь должно быть очевидно, что о передаче мультимедийной информации 
в несжатом виде не может быть и речи. К счастью, за несколько последних десят¬ 
ков лет было разработано множество методов сжатия, делающих возможной пере¬ 
дачу мультимедийной информации. В данном разделе мы рассмотрим некоторые 
методы сжатия мультимедийных данных, особенно изображений. Более подробно 
эта тема освещена в [118, 313]. 


Кроме дорогих 100-герцевых телевизоров. — Примем, перво. 
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Для всех систем сжатия требуется два алгоритма: один для компрессии данных 
у источника информации, а другой — декомпрессии у ее получателя. В литературе 
эти алгоритмы называют соответственно алгоритмами кодирования и декодиро¬ 
вания. Мы также будем пользоваться здесь этой терминологией. 

Эти алгоритмы обладают определенной асимметрией, о которой следует ска¬ 
зать несколько слов. Во-первых, во многих приложениях мультимедийный доку¬ 
мент, например фильм, кодируется всего один раз при его создании и помещении 
на мультимедийный сервер, но декодируется тысячи раз при просмотре пользова¬ 
телями. Эта асимметрия означает, что алгоритм кодирования может быть доволь¬ 
но медленным и требовать дорогого оборудования, тогда как алгоритм декодиро¬ 
вания должен быть быстрым и должен работать даже на дешевом оборудовании. 
С другой стороны, для мультимедиа реального времени, например видеоконферен¬ 
ции, медленное кодирование неприемлемо. Кодирование здесь должно происхо¬ 
дить на ходу, в режиме реального времени. 

Вторая причина асимметрия состоит в том, что процесс кодирования/декоди¬ 
рования не обязан быть обратимым. Это значит, что при сжатии обычного файла, 
его передаче и декомпрессии получатель обязан получить точную копию ориги¬ 
нала. При передаче мультимедиа абсолютная точность не требуется. Вполне допу¬ 
стимы небольшие отклонения видеосигнала от оригинала после его кодирования 
и декодирования. Система, в которой декодированный сигнал не точно соответ¬ 
ствует кодированному оригиналу, называется системой с потерями. Все системы 
сжатия данных, применяемые в мультимедиа, являются системами с потерями, так 
как они позволяют достичь гораздо большего коэффициента сжатия. 

Стандарт иРЕС 

Стандарт^ЕС для сжатия неподвижных изображений с непрерывно меняющим¬ 
ся цветом (например, фотографий) был разработан группой экспертов в области 
фотографии ^ЕС ( фоіпі; РЬо1о§гарЬу Ехрегіз Сгоир — Объединенная группа 
экспертов по машинной обработке фотоизображений). Эта группа работала под 
совместным покровительством международного союза телекоммуникаций ІТЕІ, 
Международной организации по стандартизации 150 и еще одной организации, 
занимающейся стандартизацией, ІЕС (Іпіегпаііопаі ЕІесігоіесЬпісаІ Соттіззіоп — 
международная электротехническая комиссия). Стандарт ^ЕС является очень 
важным для мультимедиа, так как в первом приближении мультимедийный стан¬ 
дарт для движущихся изображений МРЕО представляет собой просто кодирова¬ 
ние каждого кадра отдельно алгоритмом ^ЕС плюс некоторые дополнительные 
процедуры межкадрового сжатия и обнаружения движения. Стандарт ^ЕС оп¬ 
ределен как Международный стандарт 10918. У метода сжатия ^ЕС четыре ре¬ 
жима и множество параметров, но нас здесь будет интересовать только исполь¬ 
зование стандарта ^ЕС для кодирования 24-битового КСВ-видеоизображения, 
поэтому мы опустим некоторые незначительные детали. 

Первый этап кодирования изображения алгоритмом^ЕС представляет собой 
подготовку блока. Рассмотрим частный случай кодирования 24-битового КСВ- 
видеоизображения размером 640x480 пикселов, как показано на рис. 7.5, а. Посколь¬ 
ку разделение на яркость и цветность позволяют сильнее сжать изображение, снача- 
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ла из значений КСВ вычисляются яркость и два значения цветности. В стандарте 
ЫТ5С они называются У, Іи () соответственно. В стандарте РАЬ значения цветно¬ 
сти называются I) пѴп коэффициенты используются другие, но идея та же самая. 
Ниже мы будем использовать имена стандарта ЕГТ5С. 


КСВ У 



24-битовый пиксел Блок 4799 О 


а б 

Рис. 7.5. Исходные данные в формате КСВ (а); после подготовки блока (б) 

Для значений У, I и <2 строятся отдельные матрицы с элементами в диапазоне 
от 0 до 255. Затем значения цветности I и <2 усредняются по квадратным блокам 
из четырех пикселов, что уменьшает размеры матриц цветности в 4 раза до разме¬ 
ра 320x240. Это сжатие является преобразованием с потерями, но человеческий 
глаз его практически не замечает, так как чувствительность глаза к яркости значи¬ 
тельно выше, чем к цветности. Но уже на этом этапе общий объем данных уменьша¬ 
ется вдвое. Затем из каждого элемента вычитается число 128, чтобы переместить 
число 0 в середину диапазона. Наконец, каждая матрица разбивается на квадраты 
по 8x8 пикселов. Таким образом, матрица У состоит из 4800 квадратных блоков, 
а матрицы I и (5 содержат по 1200 блоков каждая, как показано на рис. 7.5, б. 

На втором этапе кодирования изображения алгоритмом 2РЕС к каждому из 
7200 квадратных блоков отдельно применяется дискретное косинусное преобра¬ 
зование. На выходе получается 7200 матриц 8x8 коэффициентов дискретного ко¬ 
синусного преобразования (ДКП). Элемент (0, 0) такой матрицы представляет 
собой среднее значение блока. Остальные элементы содержат информацию о спек¬ 
тральной мощности каждой пространственной частоты. В теории дискретное ко¬ 
синусное преобразование является преобразованием без потерь (обратимым), но 
на практике использование чисел с плавающей точкой и трансцендентных функ¬ 
ций приводят к ошибкам округления, в результате чего часть информации теряет¬ 
ся. Обычно элементы матрицы ДКП-коэффициентов быстро убывают с расстоя¬ 
нием от элемента (0, 0), как показано на рис. 7.6. 

По завершении дискретного косинусного преобразования алгоритм 2РЕС пе¬ 
реходит к этапу 3, называемому квантованием, в котором наименее важные ДКП- 
коэффициенты удаляются. Это преобразование (с потерями) выполняется деле¬ 
нием всех коэффициентов ДКП-матрицы на табличные весовые коэффициенты. 
Если все весовые коэффициенты равны 1, то это преобразование ничего не меня- 
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ет. Однако при резком росте весовых коэффициентов по мере удаления от элемен¬ 
та матрицы (0, 0) более высокие пространственные частоты быстро теряются. 




Рис. 7.6. Один блок матрицы У (а); ДКП-коэффициенты (б) 


Пример этого этапа работы алгоритма показан на рис. 7.7. Здесь мы видим ис¬ 
ходную ДКП-матрицу, таблицу квантования и результат деления каждого ДКП- 
элемента на соответствующий элемент таблицы квантования. Значения в таблице 
квантования не являются частью стандарта }РЕС. Каждое приложение должно 
содержать свою таблицу весовых коэффициентов, что позволяет ему контролиро¬ 
вать соотношение потерь и коэффициента сжатия. 


ДКП-коэффициенты 


Квантовые коэффициенты 
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Рис. 7.7. Квантование ДКП-коэффициентов 


На четвертом этапе значение, содержащееся в элементе (0, 0) каждого блока 
(в левом верхнем углу квадрата), заменяется его отклонением относительно зна¬ 
чения в предыдущем блоке. Так как эти значения представляют собой усреднен¬ 
ные величины своих блоков, они должны меняться медленно, следовательно, по¬ 
лученные в результате разности должны быть невелики. Для остальных значений 
разности не вычисляются. Значения элементов (0, 0) называются ОС-компонен¬ 
тами, а остальные элементы — АС-компонентами. 

На пятом этапе 64 элемента блока выстраиваются в ряд, к которому применяет¬ 
ся кодирование длин серий. Чтобы сконцентрировать нули в конце ряда, сканиро¬ 
вание блока выполняется зигзагом, как показано на рис. 7.8. В нашем примере в кон¬ 
це блока группируется 38 нулей. Эта строка нулей заменяется просто числом 38. 
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Рис. 7.8. Порядок передачи квантованных значений 


На последнем, шестом этапе к общему списку чисел применяется код Хаффма¬ 
на (НиЯтап). 

Алгоритм ^ЕС может показаться сложным, но это только потому, что он та¬ 
ким и является. Однако он широко применяется, так как позволяет сжимать фо¬ 
тографии в 20 и более раз. Для декодирования сжатого изображения нужно вы¬ 
полнить все те же операции в обратном порядке. В отличие от некоторых других 
алгоритмов, ІРЕО примерно симметричен: декодирование занимает столько же 
времени,сколько и кодирование. 

Стандарт МРЕС 

Наконец мы подходим к ключевому вопросу мультимедиа: стандартам МРЕС 
(Моілоп Рісіигез Ехрегіз Сгоир — Экспертная группа по вопросам движущегося 
изображения). Эти стандарты, ставшие международными в 1993 году, описывают 
основные алгоритмы, используемые для сжатия видеофильмов. Первым закончен¬ 
ным стандартом стал стандарт МРЕС-1 (Международный стандарт 11172). Его 
целью было создание выходного потока данных качества бытового видеомагни¬ 
тофона (352x240 для 1ЧТ5С) на скорости 1,2 Мбит/с. Следом появился стандарт 
МРЕС-2 (Международный стандарт 13818), разрабатывавшийся для сжатия 
видеофильмов качества широковещания до скорости потока от 4 до 6 Мбит/с, 
что позволяло передавать этот фильм в цифровом виде по стандартному телеви¬ 
зионному каналу 1ЧТ5С или РАЬ. 

В видеофильмах имеется избыточность двух типов: пространственная и вре¬ 
менная. Чтобы использовать пространственную избыточность, можно просто ко¬ 
дировать каждый кадр отдельно алгоритмом ] РЕС. Дополнительного сжатия мож¬ 
но достичь, используя преимущество того факта, что последовательные кадры 
часто бывают почти идентичны (временная избыточность). Система ЭѴ (Эіфіаі 
Ѵійео — цифровое видео), применяющаяся в цифровых видеокамерах, использу¬ 
ет только сжатие по алгоритму ІРЕС, так как кодирование должно производиться 
в режиме реального времени и значительно быстрее кодировать каждый кадр от¬ 
дельно. Последствия такой схемы видны в табл. 7.1: хотя поток данных цифровой 
видеокамеры и ниже, чем у несжатого видео, он все же не настолько хорошо сжат, 
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как МРЕС-2. (Чтобы это сравнение было честным, добавим, что БѴ-видеокамеры 
записывают значение сигнала яркости 8 битами, а каждое значение цветности — 
всего 2 битами). 

В сценах, в которых камера и задний план неподвижны и один или два актера 
медленно двигаются, почти все пикселы в соседних кадрах будут идентичны. В этом 
случае простое вычитание каждого кадра из предыдущего и обработка разности 
алгоритмом }РЕС даст достаточно хороший результат. Однако этот метод плохо 
подходит к сценам, в которых камера поворачивается или наезжает на снимаемый 
объект. Для таких сцен необходим какой-либо способ компенсировать это движе¬ 
ние камеры. В этом и состоит основное отличие МРЕС от }РЕС. 

Выход МРЕС-2 состоит из кадров следующих типов: 

1. I (Іпігасосіесі — автономные) — независимые неподвижные изображения, 
кодированные алгоритмом }РЕС. 

2. Р (Ргесіісііѵе — предсказывающие) — содержащие разностную информацию, 
относительно предыдущего кадра. 

3. В (ВіФгесІіопаІ — двунаправленные) — содержащие изменения относитель¬ 
но предыдущего и последующего кадров. 

І-кадры представляют собой обычные неподвижные изображения, кодирован¬ 
ные алгоритмом }РЕС с использованием полного разрешения яркости и половин¬ 
ного разрешения для обоих сигналов цветности. І-кадры должны периодически 
появляться в выходном потоке по трем причинам. Во-первых, должна быть воз¬ 
можность просмотра фильма не с самого начала. Зритель, пропустивший первый 
кадр, не сможет декодировать все последующие кадры, если все кадры будут зави¬ 
сеть от предыдущих, и І-кадры не будут время от времени включаться в поток. Во- 
вторых, дальнейшее декодирование фильма станет невозможным в случае ошиб¬ 
ки при передаче какого-либо кадра. В-третьих, наличие таких кадров существенно 
упростит индикацию во время быстрой перемотки вперед или назад. По этим при¬ 
чинам І-кадры включаются в выходной поток примерно один-два раза в секунду. 

Р-кадры, напротив, представляют собой разность между соседними кадрами. 
Они основаны на идее макроблоков, покрывающих 16x16 пикселов в простран¬ 
стве яркости и 8x8 пикселов в пространстве цветности. При кодировании макро¬ 
блока в предыдущем кадре ищется наиболее близкий к нему макроблок. 

Пример использования макроблоков показан на рис. 7.9. Здесь мы видим три 
последовательных кадра с одинаковым задним планом, отличающихся только по¬ 
ложением человека. Макроблоки, содержащие задний план, будут полностью со¬ 
впадать друг с другом, но макроблоки, содержащие человека, будут смещаться на 
некоторую величину. Именно для этих макроблоков алгоритм должен найти мак¬ 
симально похожие макроблоки из предыдущего кадра. 

Стандарт МРЕС не указывает, как искать, насколько далеко искать или насколь¬ 
ко хорошо должен подходить похожий макроблок. Все эти вопросы оставлены на 
усмотрение разработчика программы, реализующей стандарт МРЕС. Например, 
макроблок можно искать в предыдущем кадре в текущей позиции с заданными 
смещениями по горизонтали и вертикали. Для каждой позиции может вычисляться 
количество совпадений матрицы яркости. Позиция с наибольшим значением совпа¬ 
дений будет объявляться победительницей при условии, что это значение превос- 
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ходит некое пороговое значение. В противном случае макроблок будет считаться 
не найденным. Возможны, конечно, и значительно более сложные алгоритмы. 





Рис. 7.9. Три последовательных кадра 


Макроблок, для которого найден похожий на него макроблок в предыдущем 
кадре, кодируется в виде разности значений яркости и цветности. Затем матрицы 
разностей подвергаются дискретному косинусному преобразованию, квантованию, 
кодированию длин серий и кодированию Хаффмана так же, как это делает алго¬ 
ритм ^ЕС. В выходном потоке макроблок представляется в виде вектора сдвига 
(насколько далеко сдвинулся макроблок по горизонтали и вертикали от положе¬ 
ния в предыдущем кадре), за которым следует список чисел, кодированных по 
Хаффману. Если же в предыдущем кадре не нашлось подходящего макроблока, 
текущее значение кодируется алгоритмом,|РЕС, как в І-кадре. 

В-кадры подобны Р-кадрам с той разницей, что позволяют привязывать мак¬ 
роблок либо к предыдущему, либо к следующему кадру. Такая дополнительная 
свобода позволяет достичь лучшей компенсации движения. Для декодирования 
В-кадров необходимо удерживать в памяти сразу три кадра: предыдущий, текущий 
и следующий. Для упрощения декодирования кадры должны присутствовать в по¬ 
токе МРЕС не в порядке их отображения, а в порядке зависимостей друг от друга. 
Это означает, что при передаче видео по сети необходима буферизация данных на 
машине пользователя, чтобы изменить порядок кадров для их правильного отобра¬ 
жения. Поскольку порядок отображения кадров не совпадает с порядком их взаи¬ 
мозависимостей, для воспроизведения фильма задом наперед потребуется значи¬ 
тельная буферизация и сложные алгоритмы. 


Планирование процессов 
в мультимедийных системах 

Операционные системы, поддерживающие мультимедиа, отличаются от обычных 
систем тремя параметрами: планированием процессов, файловой системой и дис¬ 
ковым планированием. Эти темы будут рассмотрены в следующих разделах. 

Планирование однородных процессов 

Простейшая разновидность видеосервера может поддерживать отображение фик¬ 
сированного числа фильмов, использующих одинаковую скорость передачи дан¬ 
ных, видеоразрешение, частоту кадров и другие параметры. При таких условиях 
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используется эффективный алгоритм планирования. Для каждого фильма созда¬ 
ется отдельный процесс (или поток), чья работа заключается в чтении фильма 
с диска по кадру и передаче этого кадра пользователю. Поскольку все процессы 
одинаково важны, выполняют одинаковый объем работ на каждый кадр и блоки¬ 
руются, закончив обработку текущего кадра, то для управления этими процес¬ 
сами лучше всего использовать простой алгоритм поочередного планирования. 
К стандартному алгоритму следует лишь добавить механизм, следящий за вре¬ 
менными параметрами, чтобы гарантировать, что каждый процесс работает с пра¬ 
вильной частотой. 

Один способ достижения правильного временного режима состоит в исполь¬ 
зовании управляющих часов, тикающих, скажем, 30 раз в секунду (для 1ЧТ5С). При 
каждом тике все процессы запускаются последовательно в одном и том же поряд¬ 
ке. Завершив свою работу, процесс обращается к системному вызову зизрепсі, ко¬ 
торый освобождает центральный процессор до следующего тика часов. Затем все 
повторяется снова. Пока число процессов невелико и вся работа может быть вы¬ 
полнена за время длительности одного кадра, такой алгоритм планирования рабо¬ 
тает вполне успешно. 

Общее планирование реального времени 

К сожалению, простой алгоритм поочередного планирования редко может быть 
применен в реальной жизни. Количество пользователей меняется со временем, 
размеры кадров варьируются в широчайших пределах благодаря самой природе 
видеосжатия (І-кадры значительно крупнее Р-кадров и В-кадров), кроме того, 
в различных фильмах может использоваться различное разрешение. В результате 
может оказаться, что разным процессам потребуется работа с разной частотой для 
выполнения различного объема работ и с различными сроками их окончания. 

Такие соображения приводят к совершенно другой модели: нескольким про¬ 
цессам, соревнующимся за право использования центрального процессора, каж¬ 
дый со своим заданием и графиком его выполнения. В следующих моделях мы 
будем предполагать, что системе известна частота, с которой должен работать каж¬ 
дый процесс, объем работ, который ему предстоит выполнить, и ближайший срок 
выполнения очередной порции задания. (Дисковое планирование тоже важно, 
но мы обсудим этот вопрос позднее.) Планирование нескольких конкурирующих 
процессов, у некоторых (или у всех) из них есть жесткие сроки выполнения работ, 
называется планированием реального времени. 

В качестве примера среды, в которой работает мультимедийный планировщик 
реального времени, рассмотрим три процесса, А, В и С, показанные на рис. 7.10. 
Процесс А запускается каждые 30 мс (приблизительная частота 1ЧТ5С). Для об¬ 
работки каждого кадра требуется около 10 мс времени центрального процессора. 
При отсутствии конкуренции он будет запускаться импульсами А 1, А 2, ЛЗ и т. д., 
каждый из которых будет начинаться через 30 мс после предыдущего. Каждый 
10-миллисекундный интервал работы центрального процессора обрабатывает один 
кадр и должен завершить работу к определенному моменту времени, то есть преж¬ 
де, чем начнется обработка следующего кадра. 
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Рис. 7.10. Три периодических процесса воспроизведения фильмов. Частота кадров и время 
обработки кадра различны для каждого процесса 


На рис. 7.10 также показаны два других процесса: В и С. Процесс В работает с 
частотой 25 кадров в секунду (например, РАЬ), а процесс С — с частотой 20 кад¬ 
ров в секунду (например, замедленный поток ЫТ5С или РАЬ, предназначенный 
для пользователя, соединенного с видеосервером линией с низкой пропускной 
способностью). Время обработки каждого кадра показано на рисунке — 15 мс для 
процесса В и 5 мс для процесса С. 

Проблема планирования состоит в том, как в данной ситуации планировать 
работу процессов А, В и С так, чтобы гарантировать выполнение ими требуемой 
работы в срок. Прежде чем начать знакомство с алгоритмом планирования, нам 
необходимо понять, возможно ли в принципе выполнение поставленной задачи, 
то есть является ли данный набор процессов планируемым вообще. Как говорилось 
в разделе «Планирование в системах реального времени» главы 2, если у процесса і 
период равен Р, и на обработку одного кадра этого процесса уходит С, секунд рабо¬ 
ты процессора, то система будет планируемой только в том случае, если 



где т — количество процессов, в данном случае 3. Обратите внимание, что С ; /Р,- 
является просто частью процессорного времени, используемой процессом і. На¬ 
пример, на рис. 7.10 процесс А съедает 10/30 времени центрального процессо¬ 
ра, процесс В съедает 15/40 времени центрального процессора, а процесс С съеда¬ 
ет 5/50 времени центрального процессора. Суммарно эти процессы потребляют 
0,808 процессорного времени, что меньше единицы, и, следовательно, система яв¬ 
ляется планируемой. 

До сих пор предполагалось наличие только одного процесса для каждого пото¬ 
ка данных. В действительности их может быть два (и более), например один про¬ 
цесс для аудио и один для видео. Они могут работать с различными скоростями 
передачи данных и могут потреблять разное количество процессорного времени 
для каждого кадра. 
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В некоторых системах реального времени процессы являются прерываемыми, 
тогда как в других системах — нет. В мультимедийных системах процессы, как 
правило, могут прерываться. Это означает, что процесс, которому угрожает не¬ 
выполнение задачи в срок, может прервать работающий процесс прежде, чем тот 
успеет закончить обработку своего кадра. Затем управление может быть возвра¬ 
щено прерванному процессу. Такое поведение процессов представляет собой мно¬ 
гозадачность, о которой уже говорилось в предыдущих главах. Мы рассмотрим 
алгоритмы планирования реального времени с прерываниями, так как они не про¬ 
тиворечат принципам мультимедийных систем и позволяют достичь лучших по¬ 
казателей производительности, чем алгоритмы без прерываний. Единственная за¬ 
бота состоит в том, что при заполнении буфера за короткие интервалы времени 
буфер должен быть заполнен в срок, чтобы его можно было отправить за одну опе¬ 
рацию. В противном случае может возникнуть джиттер. 

Алгоритмы реального времени могут быть статическими или динамическими. 
Статические алгоритмы заранее назначают каждому процессу фиксированный 
приоритет, после чего выполняют приоритетное планирование с переключения¬ 
ми. У динамических алгоритмов нет фиксированных приоритетов. Мы изучим 
примеры обоих типов алгоритмов. 

Алгоритм планирования ВМ8 

Классическим примером статического алгоритма планирования реального време¬ 
ни для прерываемых, периодических процессов является алгоритм КМ8 (Каіе 
Мопоіопіс 5сЬесіи1іп§ — планирование с приоритетом, пропорциональным часто¬ 
те) [212]. Этот алгоритм может использоваться для процессов, удовлетворяющих 
следующим условиям: 

1. Каждый периодический процесс должен быть завершен за время его периода. 

2. Ни один процесс не должен зависеть от любого другого процесса. 

3. Каждому процессу требуется одинаковое процессорное время на каждом 
интервале. 

4. У непериодических процессов нет жестких сроков. 

5. Прерывание процесса происходит мгновенно, без накладных расходов. 

Первые четыре требования разумны. Последнее, естественно, нет, но оно зна¬ 
чительно упрощает модель системы. Алгоритм КМ5 работает, назначая каждому 
процессу фиксированный приоритет, равный частоте возникновения событий процес¬ 
са. Например, процесс, который должен запускаться каждые 30 мс (33 раза в секун¬ 
ду), получает приоритет 33; процесс, который должен запускаться каждые 40 мс 
(25 раз в секунду), получает приоритет 25; а процесс, который должен запускать¬ 
ся каждые 50 мс (20 раз в секунду), получает приоритет 20. Таким образом, при¬ 
оритеты пропорциональны частоте (количеству раз в секунду, которые запускает¬ 
ся процесс). Отсюда и название алгоритма. Во время работы планировщик всегда 
запускает готовый к работе процесс с наивысшим приоритетом, прерывая при 
необходимости работающий процесс. Авторы алгоритма доказали, что КМ5 явля¬ 
ется оптимальным решением в классе статических алгоритмов планирования. 
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Рис. 7.11. Пример алгоритмов планирования реального времени НМЗ и ЕЭР 


На рис. 7.11 показана работа алгоритма планирования КМ5 в ситуации приме¬ 
ра предыдущего рисунка. Процессам А, В и С назначены статические приоритеты 
33, 25 и 20 соответственно; это означает, что когда процесс А желает работать, он 
работает, прерывая любой другой процесс, использующий центральный процессор 
в данный момент. Процесс В может прервать работу процесса С, но не Л. Процесс С 
вынужден ждать, пока центральный процессор не освободится. 

Изначально все три процесса готовы к работе (см. рис. 7.11). Выбирается процесс 
с максимальным приоритетом, то есть процесс А. Ему разрешается работать в тече¬ 
ние 15 мс, требующихся процессу, чтобы полностью выполнить работу по передаче 
одного кадра (это показано в строке рисунка, помеченной КМ5). Когда процессу! 
заканчивает свою работу, запускается процесс В, а затем процесс С. Вместе эти 
процессы потребляют 30 мс процессорного времени, поэтому, когда процесс С за¬ 
канчивает свою работу, пора снова запускать процесс А. Этот цикл повторяется до 
тех пор, пока в момент времени 1 = 70 у системы начинается период простоя. 

В момент времени I = 80 процесс В переходит в состояние готовности и запускает¬ 
ся. Однако в момент времени 1 = 90 процесс А, обладающий более высоким приори¬ 
тетом, также переходит в состояние готовности, поэтому он прерывает выполне¬ 
ние процесса В и работает, пока не закончит свою работу к моменту времени 1= 100. 
В этом месте система должна выбрать между завершением процесса В и запуском 
процесса С. Выбирается, естественно, процесс В с более высоким приоритетом. 


Алгоритм планирования ЕЭР 

Другим популярным алгоритмом планирования является алгоритм ЕБР (Еагііезі 
БеасШпе Еігзі — процесс с ближайшим сроком завершения в первую очередь). 
Алгоритм ЕЭЕ представляет собой динамический алгоритм, в отличие от преды¬ 
дущего алгоритма не требующий от процессов периодичности. Он также не требует 
и постоянства временных интервалов использования центрального процессора. 
Каждый раз, когда процессу требуется процессорное время, он объявляет о своем 
присутствии и о своем сроке выполнения задания. Планировщик хранит список 
процессов, сортированный по срокам выполнения заданий. Алгоритм запускает 
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первый процесс в списке, то есть тот, у которого самый близкий по времени срок 
выполнения. Когда новый процесс переходит в состояние готовности, система 
сравнивает его срок выполнения со сроком выполнения текущего процесса. Если 
у нового процесса график более жесткий, он прерывает работу текущего процесса. 

Пример работы алгоритма ЕБР показан на рис 7.11. Вначале все процессы 
находятся в состоянии готовности. Они запускаются в порядке своих крайних 
сроков. Процесс Л должен быть выполнен к моменту времени I = 30, процесс В 
должен закончить работу к моменту времени I = 40, и процесс С должен завершить 
работу к моменту времени I = 50. Таким образом, процесс А запускается первым. 
Вплоть до момента времени I = 90 выбор алгоритма ЕБР не отличается от КМ5. 
В момент времени I = 90 процесс А снова переходит в состоянии готовности с тем 
же крайним сроком завершения I = 120, что и у процесса Л. Планировщик имеет 
право выбрать любой из процессов, но поскольку с прерыванием процесса В не свя¬ 
зано никаких накладных расходов, лучше предоставить возможность продолжать 
работу этому процессу. 

Чтобы не дать сложиться ложному представлению, будто бы алгоритмы КМ5 
и ЕБР всегда дают один и тот же результат, рассмотрим другой пример, показан¬ 
ный на рис. 7.12. В этом примере периоды процессов Л, Л и С те же, что и прежде, 
но теперь процессу Л на передачу одного кадра требуется 15 мс процессорного 
времени вместо 10 мс. Тест планируемости дает коэффициент использования 
процессора, равный 0,500 + 0,375 + 0,100 = 0,975. В запасе остается всего лишь 2,5 % 
времени центрального процессора, но теоретически коэффициент использования 
процессора не превышает допустимого предела, поэтому для данного случая дол¬ 
жен существовать метод планирования. 
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Рис. 7.12. Другой пример алгоритмов планирования реального времени ВМЗ и ЕЭР 

В алгоритме КМ5 приоритеты трех процессов по-прежнему равны 33, 25 и 20, 
так как на них влияют только периоды, а не времена работы. На этот раз процесс Л1 
завершает работу к моменту времени I ** 30, однако в этот момент процесс Л снова 
приходит в состояние готовности. К тому моменту, когда он заканчивает свою рабо¬ 
ту (I - 45), процесс Л также уже снова готов работать, и поскольку у него приори- 
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тет выше, чем у процесса С, то запускается процесс В, а процесс С пропускает свой 
критический срок. Таким образом, алгоритм К.М5 терпит фиаско. 

Теперь посмотрим, как алгоритм ЕБР справляется с данным случаем. В момент 
времени г = 30 между процессами А2 и С 1 возникает спор. Поскольку срок выпол¬ 
нения процесса С 1 равен 50 мс, а срок выполнения процесса А2 равен 60 мс, пла¬ 
нировщик выбирает процесс С. Этим данный алгоритм отличается от К.М5, в ко¬ 
тором побеждает процесс А, как обладающий более высоким приоритетом. 

В момент времени і = 90 процесс А приходит в состояние готовности в четвер¬ 
тый раз. Предельный срок процесса А такой же, что и текущего процесса (120 мс), 
поэтому у планировщика появляется выбор: прервать работу процесса В или нет. 
Поскольку необходимости прерывать процесс В нет, то процессу ВЗ разрешается 
продолжать работу. 

В данном примере центральный процессор занят на все 100 % до момента вре¬ 
мени (= 150. Однако в конце концов перерыв в его работе наступает, так как цент¬ 
ральный процессор занят всего на 97,5 %. Поскольку время и начала и окончания 
работ во всех случаях кратно 5 мс, промежуток простоя центрального процессора 
будет составлять 5 мс. Чтобы относительное время простоя было равно 2,5 %, 
5-миллисекундный интервал бездействия должен происходить каждые 200 мс, что 
не поместилось на рис. 7.12. 

Интересно, почему потерпел неудачу алгоритм К.М5. В основном дело в том, 
что использование статических приоритетов работает только при не слишком вы¬ 
сокой загруженности центрального процессора. Как показали Лю иЛэйланд [212], 
алгоритм КМ5 гарантированно работает в любой системе периодических процес¬ 
сов при условии 

т 

1=1 Л 

Для 3, 4, 5, 1.0, 20 и 100 процессов максимальная разрешенная загруженность 
процессора составляет 0,780,0,757,0,743,0,718,0,705 и 0,696. При т —> °° значение 
максимальной загруженности процессора асимптотически стремится к 1п 2. Дру¬ 
гими словами, Лю и Лэйланд доказали, что для трех процессов алгоритм К.М5 все¬ 
гда работает при коэффициенте загруженности центрального процессора не выше 
0,780. В нашем первом примере коэффициент загруженности составлял 0,808, и 
алгоритм К.М5 работал, но нам просто повезло. С другими периодами и временем 
работы процессов данный алгоритм может потерпеть неудачу при такой загружен¬ 
ности центрального процессора. Во втором примере коэффициент загруженности 
центрального процессора оказался настолько высок (0,975), что на возможность 
работы алгоритма К.М5 просто не было надежды. 

Алгоритм ЕБР, напротив, всегда работает с любым набором процессов, для ко¬ 
торого возможно планирование. Коэффициент загруженности центрального про¬ 
цессора для алгоритма ЕБР может достигать 100 %. Платой за это является исполь¬ 
зование более сложного алгоритма. Таким образом, на реальном видеосервере при 
загруженности центрального процессора ниже предела К.М5 может использовать¬ 
ся алгоритм К.М5. В противном случае должен применяться алгоритм ЕБР. 
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Парадигмы мультимедийной 
файловой системы 

Описав планирование процессов в мультимедийных системах, продолжим наше 
изучение мультимедийных файловых систем. В этих файловых системах применя¬ 
ются парадигмы, отличные от используемых в традиционных файловых системах. 
Сначала мы рассмотрим традиционный файловый ввод-вывод, затем обратим вни¬ 
мание на то, как организованы мультимедийные файловые серверы. Для доступа 
к файлу процесс сначала обращается к системному вызову ореп. Если эта опера¬ 
ция проходит успешно, процессу возвращается нечто вроде маркера, называемого 
дескриптором или описателем файла. С этого момента процесс может обращаться 
к системному вызову геасі, указывая на входе полученный маркер, адрес буфера и 
счетчик байтов в качестве параметров. При этом операционная система возвраща¬ 
ет в буфер требуемые данные. Пока процесс не завершил свою работу, он может 
издавать дополнительные системные вызовы геасі, а затем процесс должен обратить¬ 
ся к системному вызову сі озе, чтобы закрыть файл и вернуть ресурсы системе. 

Для мультимедиа эта модель работает плохо, так как не отвечает требованиям 
реального времени. Особенно плохо подходит такая схема для отображения муль¬ 
тимедийных файлов, поступающих с видеосервера. Одна проблема состоит в том, 
что пользователь должен обращаться к системному вызову геасі через точные ин¬ 
тервалы времени. Вторая проблема заключается в том, что видеосервер должен 
предоставлять данные без задержки, что сложно в ситуации, когда запросы посту¬ 
пают стихийно, а ресурсы не резервируются заранее. 

Для решения этих проблем мультимедийными файловыми серверами исполь¬ 
зуется совершенно другая парадигма: они действуют подобно кассетным видео¬ 
магнитофонам. Для чтения мультимедийного файла пользовательский процесс 
обращается к системному вызову зіагі, указывая файл, который следует прочи¬ 
тать, а также другие параметры, например какую звуковую дорожку и субтитры 
использовать. Затем видеосервер начинает посылать кадры с требуемой частотой. 
Принять их и обработать является задачей пользователя. Если пользователю на¬ 
скучит фильм, он может остановить поступающий поток при помощи системного 
вызова з!:ор. Файловые серверы, работающие по такой схеме, часто называют пуш- 
серверами (ризЬ зегѵегз, то есть серверы, «толкающие» данные пользователю). 
Традиционные серверы, у которых пользователь должен запрашивать данные поблоч¬ 
но, в цикле обращаясь к системному вызову геасі, называют пул-серверами (риіі 
зегѵегз). Различие между этими двумя моделями проиллюстрировано на рис. 7.13. 

Функции управления видеомагнитофоном 

Большинство видеосерверов также реализуют стандартные управляющие функ¬ 
ции видеомагнитофонов, включая паузу, быструю перемотку вперед и назад. Пау¬ 
за реализуется просто. Пользователь посылает видеосерверу сообщение с просьбой 
остановить поток данных. Все, что требуется от видеосервера, — это запомнить, 
с какого кадра продолжать передачу. Когда пользователь просит сервер возобно¬ 
вить передачу, тот просто продолжает с места, на котором был остановлен. 
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Рис. 7.13. Пул-сервер (а); пуш-сервер (б) 

Однако здесь имеется одна проблема. Для достижения приемлемой произво¬ 
дительности сервер может зарезервировать для каждого исходящего потока такие 
ресурсы, как пропускную способность диска и буферы памяти. Продолжать удер¬ 
живать эти ресурсы, в то время как фильм стоит на паузе, неэффективно. Сервер 
может освобождать ресурсы на время паузы, но при этом возникает опасность, что 
когда пользователь захочет продолжить просмотр фильма, эти ресурсы уже будут 
заняты. 

Перемотка на начало фильма также очень проста и обходится без каких-либо 
проблем. Все, что нужно сделать серверу, — это просто начать передавать фильм 
снова с кадра номер 0. Что может быть проще? Однако быстрая перемотка вперед 
или назад (то есть с воспроизведением при перемотке) значительно сложнее. Если 
бы не временное сжатие, применяемое в МРЕС, для быстрой перемотки вперед с 
удесятеренной скоростью было бы достаточно просто отображать каждый десятый 
кадр. Для ускорения в 20 раз нужно было бы отображать каждый 20-й кадр. В самом 
деле, при отсутствии сжатия быстрая перемотка вперед и назад не представляют 
трудностей. Для быстрой перемотки вперед с ускорением в к раз достаточно про¬ 
сто отображать каждый к -й кадр. Для быстрой перемотки назад в к раз быстрее 
нормальной скорости нужно выполнять те же действия в противоположном на¬ 
правлении. Этот подход в равной мере годится для пул-серверов и пуш-серверов. 

Все становится значительно сложнее из-за сжатия. В случае видеокамеры, хра¬ 
нящей каждый кадр в сжатом виде, независимо от других кадров, такая стратегия 
может использоваться при условии, что каждый кадр может быть быстро найден. 
Поскольку каждый кадр сжимается по-разному, в зависимости от его содержимо¬ 
го, каждый кадр в сжатом виде имеет различный размер, поэтому пропуск к кадров 
не может быть выполнен простым умножением размера кадра на к. Кроме того, 
звук сжимается отдельно от изображения, поэтому для каждого отображаемого 
в ускоренном режиме видеокадра должен быть также обнаружен правильный 
аудиокадр (если только звук не отключается при быстрой перемотке). Таким 
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образом, для быстрой перемотки файла формата Оі§йа1 Ѵісіео требуется индекс, 
позволяющий быстро находить нужные кадры, но по крайней мере теоретически 
такая задача вполне выполнима. 

С файлами в формате МРЕС такая схема не работает даже в теории, так как 
в данном стандарте используются І-, Р- и В-кадры. Пропуск к кадров может при¬ 
вести к тому, что программа получит следующим Р-кадр, для правильной рас¬ 
шифровки которого необходим пропущенный І-кадр. Без базового кадра относи¬ 
тельные величины, хранящиеся в Р-кадре, бесполезны. Таким образом, стандарт 
МРЕС требует последовательного воспроизведения файла. 

Для решения этой проблемы можно попытаться действительно воспроизводить 
файл последовательно с удесятеренной скоростью. Однако для этого требуется 
считывание данных с диска в десять раз быстрее. Затем сервер может попытаться 
распаковать кадры (чего он не делает при нормальной работе), определить, кото¬ 
рый кадр требуется, и снова запаковать каждый 10-й кадр как І-кадр. Однако это 
явится колоссальной нагрузкой на сервер. Кроме того, от сервера требуется пони¬ 
мание формата сжатия данных, что в нормальных условиях ему не нужно. 

Альтернативное решение состоит в передаче всех данных по сети пользовате¬ 
лю. Однако это решение потребует работы сети на десятикратной скорости, что, 
возможно, и достижимо, но не слишком просто, учитывая и без того высокие 
скорости, на которых приходится работать мультимедийным сетям в нормальной 
ситуации. 

В общем, простого решения этой проблемы не существует. Единственная осу¬ 
ществимая стратегия заключается в заблаговременном создании специального 
файла, содержащего, скажем, каждый 10-й кадр, и сжатии этого файла с помощью 
обычного алгоритма МРЕС. Этот файл был показан на рис. 7.2 как «быстрая пере¬ 
мотка вперед». Для переключения в режим быстрой перемотки вперед серверу 
нужно всего лишь определить, в каком месте этого файла находится в данный 
момент текущий указатель просматриваемого фильма. Например, если номер 
текущего кадра равен 48 210, а файл быстрой перемотки вперед ускоряет просмотр 
в 10 раз, то сервер должен найти в этом файле кадр 4821 и начать его воспроизве¬ 
дение с нормальной скоростью. Конечно, этот кадр может оказаться Р- или В-кад- 
ром, но клиентский процесс декодирования может просто пропустить их, пока не 
наткнется на І-кадр. Обратная перемотка реализуется аналогично при помощи 
второго специально приготовленного файла. 

Когда пользователь переключается обратно в режим нормального воспроизве¬ 
дения, сервер должен произвести обратный перерасчет номеров кадров и переклю¬ 
читься на нормальный файл. 

Хотя наличие этих двух специальных файлов позволяет реализовать быструю 
перемотку вперед и назад, у такого подхода имеются некоторые недостатки. Во- 
первых, для хранения дополнительных файлов требуется дополнительное диско¬ 
вое пространство. Во-вторых, при этом быстрая перемотка вперед и назад может 
выполняться только на скоростях, соответствующих скоростям этих специальных 
файлов. В-третьих, для переключения из одного режима в другой и обратно требу¬ 
ется дополнительное усложнение серверной части. 
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«Почти видео по заказу» 

Если к пользователей одновременно смотрят один и тот же фильм, на сервер ло¬ 
жится практически такая же нагрузка, как если бы они смотрели к различных 
фильмов. Однако при небольшом изменении существующей модели можно дос¬ 
тичь большого выигрыша в производительности. Видео по заказу предоставляет 
возможность пользователям начать смотреть фильм в произвольный момент. По¬ 
этому, если 100 пользователей начнут просмотр нового фильма около 8 часов ве¬ 
чера, есть шанс, что никто из них не подаст запрос одновременно, и, следовательно, 
они не смогут совместно воспользоваться одним потоком. Можно существенно 
оптимизировать данную схему, разрешив пользователям начинать просмотр филь¬ 
ма не в любой момент, а с интервалом в 5 мин. Таким образом, если пользователь 
захочет смотреть фильм в 20:02, показ фильма для него начнется в 20:05. 

Выигрыш такой стратегии заключается в том, что для 2-часового фильма по¬ 
требуется всего 24 потока данных, независимо от того, сколько зрителей будут 
смотреть этот фильм. Как показано на рис. 7.14, первый поток начинается в 20:00. 
В 20:05, когда первый поток передает кадр номер 9000, начинается передача пото¬ 
ка 2. В 20:10, когда первый поток передает кадр номер 18 000, а второй поток пере¬ 
дает кадр номер 9000, начинается передача потока 3 и т. д. до потока 24, начинаю¬ 
щегося в 21:55. В 22:00 поток 1 завершается и начинается снова с кадра 0. Эта схема 
называется «почти видео по заказу», так как показ фильма не начинается сразу 
после поступления заказа, а некоторое время спустя. 
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Рис. 7.14. В схеме «почти видео по заказу» новый поток запускается через 
равные интервалы времени, например 5 мин (9000 кадров) 
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Ключевым параметром в данной схеме является частота запусков потоков. Если 
потоки запускать через каждые 2 мин, то для демонстрации 2-часового фильма 
потребуется 60 потоков, зато максимальное время ожидания начала просмотра 
будет всего 2 мин. Оператор должен принять решение об этом параметре, так как 
увеличение интервала между потоками позволит увеличить эффективность сис¬ 
темы, увеличив количество одновременно демонстрируемых фильмов. Альтерна¬ 
тивная стратегия состоит в том, что фильм запускается сразу же, но такая служба 
будет обходиться клиенту дороже. 

В каком-то смысле видео по заказу напоминает такси: вы звоните, и оно приез¬ 
жает. «Почти видео по заказу» больше напоминает автобус, ходящий по расписа¬ 
нию, вам нужно всего лишь подождать следующего. Но общественный транспорт 
имеет смысл только в том случае, когда требуется перевезти большое количество 
людей. Автобус, проходящий по центральному Манхеттену каждые 5 мин, может 
рассчитывать на нескольких пассажиров. Автобус, двигающийся по второстепен¬ 
ным дорогам Вайоминга, может быть пуст почти всю дорогу. Аналогично, показ 
последнего фильма Стивена Спилберга может привлечь достаточное количество 
зрителей, чтобы запускать новый поток с фильмом каждые 5 мин, но для «Унесен¬ 
ных ветром», возможно, лучше подойдет вариант индивидуального заказа. 

В системе «почти видео по заказу» пользователи не имеют возможности управ¬ 
лять демонстрацией фильма. Пользователь не может поставить фильм на паузу, 
чтобы прогуляться на кухню. В данном случае по возвращении из кухни пользова¬ 
телю придется переключиться на другой канал, показывающий этот фильм с опоз¬ 
данием на 5 или 10 мин. 

В принципе такая система видео может быть частично интерактивной, то есть 
не просто запускать один фильм с интервалом в 5 мин, а делать это по просьбам 
зрителей. Раз в 5 мин такая система проверяет, на какие фильмы поступают зака¬ 
зы, и показывает именно их. При таком подходе фильм может начаться по заказу, 
например, в 20:00, 20:10, 20:15 и 20:25, но не в промежутках между этими времена¬ 
ми. В результате потоки, у которых нет зрителей, не занимают линию, экономя 
также пропускную способность диска и память видеосервера. С другой стороны, 
атака на холодильник в такой ситуации становится рискованным предприятием, 
так как нет никакой гарантии, что вы сможете переключиться на другой поток, 
отстающий на 5 мин от только что просматриваемого вами. Конечно, оператор 
может предоставить пользователям список всех передаваемых в данный момент 
потоков, однако многие телезрители полагают, что у пультов дистанционного 
управления их телевизоров и так слишком много кнопок, поэтому они вряд ли 
обрадуются появлению еще одной. 

«Почти видео по заказу» с функциями 
видеомагнитофона 

Идеальной комбинацией было бы «почти видео по заказу» (с его экономичностью) 
плюс полный комплект возможностей видеомагнитофона для каждого индивиду¬ 
ального пользователя (для удобства зрителя). При небольших изменениях такая 
модель осуществима. Ниже будет дано слегка упрощенное описание одного из спо¬ 
собов достижения данной цели [2]. 
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Мы начнем со стандартной схемы «почти видео по заказу» (см. рис. 7.14). Одна¬ 
ко добавим к ней требование локального буферирования на машине клиента пре¬ 
дыдущих АТ мин и последующих Д Т мин фильма. Буферизация предыдущих АТ мин 
не представляет трудности: нужно просто сохранять поступающие данные после 
их отображения. Буферизация последующих АТ мин фильма несколько сложнее, 
но также осуществима, если машина клиента способна принимать сразу два потока. 

Проиллюстрируем на примере один вариант установки буфера. Если пользо¬ 
ватель начинает просмотр в 8:15, клиентская машина читает и отображает поток 
8:15, который передает кадр 0. Параллельно она читает и сохраняет на диске по¬ 
ток, начавшийся в 8:10, находящийся в данный момент на 5-минутной отметке (то 
есть кадр 9000). В 8:20 кадры от 0 до 17 999 сохранены на диске, а пользователь 
собирается смотреть кадр 9000. С этого момента поток 8:15 более не нужен, так 
как буфер заполнен потоком 8:10 (который передает кадр 18 000), и клиентская 
машина может продолжать отображение из середины буфера (кадр 9000). При чте¬ 
нии каждого кадра один новый кадр добавляется в буфер с одного конца, а с дру¬ 
гого конца буфера один кадр удаляется. Кадр, отображаемый в данный момент, 
называемый точкой воспроизведения, всегда находится в середине буфера. Ситу¬ 
ация 75-й минуты фильма показана на рис. 7.15, а. На этом рисунке все кадры от 
70-й до 80-й минуты фильма находятся в буфере. При скорости передачи данных 
4 Мбит/с 10-минутный буфер должен иметь размер в 300 млн байт. При сегодняш¬ 
них ценах такой буфер, конечно, может храниться на диске и, возможно, в ОЗУ. 
Если требуется ОЗУ, но буфер в 300 млн байт кажется чрезмерным, можно исполь¬ 
зовать буфер меньших размеров. 

Теперь предположим, что пользователь решает перемотать фильм вперед или 
назад. Пока точка воспроизведения остается в интервале 70-80 мин, процесс ото¬ 
бражения может получать данные из буфера. Однако если точка воспроизведения 
переместится за пределы этого интервала, возникает проблема. Решение заключа¬ 
ется в переключении на персональный (то есть видео по заказу) канал обслужива¬ 
ния пользователя. Для быстрого перемещения в любом направлении могут исполь¬ 
зоваться обсуждавшиеся ранее методы. 

Как правило, в некоторый момент пользователь прекращает быструю перемот¬ 
ку и решает продолжить просмотр фильма в нормальном режиме. В этот момент 
можно подумать о том, чтобы переместить пользователя на один из потоков «по¬ 
чти видео по заказу», чтобы освободить более дорогой индивидуальный канал. 
Предположим, например, что пользователь решает вернуться на 12-минутную от¬ 
метку (рис. 7.15, б). Эта отметка находится далеко за пределами буфера, поэтому 
для продолжения показа фильма буфер оказывается бесполезен. Более того, по¬ 
скольку пользователь (мгновенно) переключился на 12-ю минуту с 75-й минуты 
фильма, то имеются потоки, демонстрирующие этот фильм на 5-й, 10-й, 15-й и 
20-й минуте, но ни одного на 12-й. 

Решение состоит в продолжении просмотра индивидуального канала, но с 
одновременным заполнением буфера из потока, показывающего в данный момент 
15-ю минуту фильма. Ситуация через 3 мин после этого показана на рис. 7.15, в. 
Теперь точка воспроизведения находится на отметке 15 мин, в буфере содержатся 
данные фильма с 15-й по 18-ю минуту, а потоки «почти видео по заказу», среди 
прочих, демонстрируют 8-ю, 13-ю, 18-ю и 23-ю минуты. В этот момент индивиду¬ 
альный поток может быть освобожден, а отображение может далее получать дан- 
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ные из буфера. Буфер продолжает пополняться из потока, передающего в этот 
момент 18-ю минуту. Еще через минуту точка воспроизведения перемещается на 
16-ю минуту фильма, в буфере к этому моменту содержатся минуты от 15-й по 
19-ю, а из потока в буфер поступает 19-я минута (рис. 7.15, г). 
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Рис. 7.15. Начальная ситуация (а); после обратной перемотки на 12 мин (б); после 
3-минутного ожидания (в); буфер начинает заполняться (г); буфер полон (д) 

Еще через 6 мин буфер заполняется, при этом точка воспроизведения находит¬ 
ся на 22-й минуте фильма. Теперь она не в середине буфера, но при необходимос¬ 
ти и этот вопрос может быть решен. 


Размещение файла 

Размер мультимедийных файлов очень велик. Мультимедийные файлы, как пра¬ 
вило, записываются всего один раз, но много раз считываются. Доступ к мульти¬ 
медийным файлам чаще всего последовательный. Их воспроизведение также долж- 
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но удовлетворять строгим критериям качества обслуживания. Все эти свойства 
мультимедийных файлов предполагают использование компоновки файловой 
системы, отличной от используемой в традиционных операционных системах. 
Некоторые из этих вопросов будут рассмотрены ниже, сначала мы рассмотрим 
однодисковый вариант хранения файла, а затем многодисковый. 


Размещение файла на одном диске 

Самое важное требование заключается в том, чтобы данные могли передаваться 
в сеть или выходное устройство с требуемой скоростью и без джиттера. По этой 
причине выполнение нескольких операций поиска цилиндра во время считыва¬ 
ния кадра крайне нежелательно. Одним из способов устранения излишних пере¬ 
мещений блока головок на сервере является использование непрерывных файлов. 
Поскольку файлы с фильмами не изменяются после записи их на сервер, такая 
схема является реализуемой и работоспособной. 

Однако имеется одна проблема, связанная с тем, что в таком файле одновре¬ 
менно должны храниться видео- и аудиоданные, а также текстовая информация 
(см. рис. 7.2). Даже если вся эта информация хранится в отдельных непрерывных 
файлах, потребуются операции поиска цилиндра при переключении с видеофай¬ 
ла на аудиофайл, а с него на текстовый файл. В результате был разработан другой 
вариант хранения, с чередованием видео-, аудио- и текстовой информации в од¬ 
ном файле (рис. 7.16). При этом сам файл остается непрерывным. В таком файле 
сразу за первым видеокадром следуют различные звуковые дорожки к первому 
кадру, а затем различные текстовые данные к этому же кадру. В зависимости от 
того, насколько много содержится в файле звуковых и текстовых дорожек, может 
оказаться проще прочитать их все за одну дисковую операцию, а пользователю 
передать только требующуюся часть этой информации. 
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Рис. 7.16. Чередование видео-, аудио- и текстовой информации в одном непрерывном файле 


Подобная организация требует дополнительных операций ввода-вывода для 
чтения ненужных звуковых дорожек и текста и дополнительного буферного про¬ 
странства в памяти для их хранения. Однако такой подход устраняет все лишние 
операции по перемещению блока головок (в однопользовательской системе), а так¬ 
же накладные расходы по учету расположения кадров на диске, так как все кадры 
располагаются в непрерывном файле друг за другом. Правда, при таком разме¬ 
щении файла становится невозможным произвольный доступ к файлу, но если он 
не требуется, то такая потеря не страшна. Также без дополнительных структур 
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данных и усложнения алгоритмов невозможной становится быстрая перемотка 
вперед и назад. 

Преимущество размещения всего фильма в виде одного непрерывного файла 
теряется на видеосервере, обслуживающем одновременно несколько выходных 
потоков, так как после чтения одного кадра фильма, прежде чем диск получит за¬ 
прос на чтение следующего кадра, серверу потребуются кадры из других фильмов. 
Кроме того, в системе, в которой фильмы не только считываются, но и записывают¬ 
ся (то есть используемой для производства или редактирования видеофильмов), 
использование огромных непрерывных файлов неудобно и трудно выполнимо. 

Две альтернативные стратегии 
организации файлов 

Результатом описанных выше наблюдений явилось создание двух альтернативных 
стратегий организации мультимедийных файлов. Первая из них, представляющая 
собой использование дисковых блоков небольшого размера, показана на рис. 7.17. 
В данной схеме размер блоков диска выбирается существенно меньшим, чем сред¬ 
ний размер кадра, даже Р-кадров и В-кадров. Для формата МРЕС-2 со скоростью 
4 Мбит/с при 30 кадрах в секунду средний кадр имеет размер около 16 Кбайт, по¬ 
этому в данном варианте хорошо подойдут дисковые блоки размером 1 Кбайт или 
2 Кбайт. Идея заключается в том, чтобы получить структуру данных, а именно 
индекс кадров для каждого фильма, с указателями на начало каждого кадра. Каж¬ 
дый кадр содержит всю видео-, аудио- и текстовую информацию для этого кадра 
в виде непрерывной последовательности дисковых блоков (см. рис. 7.17). Таким 
образом, чтобы прочитать кадр к, нужно найти в индексе к -й элемент, а затем счи¬ 
тать весь кадр за одну дисковую операцию. Поскольку различные кадры имеют 
различный размер, этот размер (в блоках) должен содержаться в индексе. Но при 
1-килобайтных дисковых блоках 8-битового поля будет вполне достаточно, чтобы 
поддерживать кадры размером до 255 Кбайт, а этого достаточно для несжатого 
ЫТ5С, даже при большом количестве звуковых дорожек. 

Другой способ хранения фильма показан на рис. 7.17, б. В этом случае исполь¬ 
зуются дисковые блоки большого размера (например, 256 Кбайт), и в каждый та¬ 
кой блок помещается несколько кадров. Индекс также нужен, но теперь это уже 
не индекс кадров, а индекс блоков. В принципе данный индекс почти не отличает¬ 
ся от і-узла (см. рис. 6.12), возможно, с добавлением информации, сообщающей но¬ 
мер кадра, с которого начинается блок, что позволяет быстро находить нужные 
кадры. В общем случае целое число кадров не поместится в один блок. Существу¬ 
ет два варианта решения данной проблемы. 

Во-первых, оставшуюся часть блока можно оставлять неиспользуемой 
(рис. 7.17, б). При этом часть дискового пространства будет теряться, что пред¬ 
ставляет собой внутреннюю фрагментацию (то же, что и в системе виртуальной 
памяти со страницами фиксированного размера). С другой стороны, при таком 
подходе никогда не придется посреди чтения кадра выполнять операцию поиска 
дискового цилиндра. 
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Рис. 7.17. Сегментированное хранение фильма: маленькие дисковые блоки (а); 
большие дисковые блоки (б) 


Во-вторых, оставшаяся часть блока может заполняться частью кадра. В резуль¬ 
тате при чтении кадра может потребоваться перемещение блока головок, что сни¬ 
зит производительность, но зато позволит сэкономить некоторую часть дискового 
пространства, так как внутренняя фрагментация будет устранена. 

В первом варианте хранения файлов на диске, состоящем из небольших бло¬ 
ков (см. рис. 7.17, а), также терялась определенная часть дискового пространства, 
потому что часть последнего блока в каждом кадре тоже не использовалась. При 
килобайтных дисковых блоках 2-часовой фильм в формате ЫТ5С состоит из 
216 000 кадров. При этом потери дискового пространства будут составлять всего 
108 Кбайт из 3,6 Гбайт. Для ситуации на рис. 7.17, б потери дискового простран¬ 
ства сосчитать сложнее. Можно лишь сказать, что они будут значительно больши¬ 
ми, так как время от времени в конце блока неиспользованными будут оставаться 
фрагменты блока размером порядка 100 Кбайт, в случае когда следующий І-кадр 
окажется больше этого размера. 

С другой стороны, блоковый индекс занимает существенно меньше места, не¬ 
жели кадровый индекс. При 256-килобайтных дисковых блоках и среднем разме¬ 
ре кадров в 16 Кбайт в блок будет помещаться около 16 кадров, поэтому для филь¬ 
ма из 216 000 кадров потребуется всего около 13 500 элементов блочного индекса, 
против 216 000 для кадрового индекса. Для повышения производительности в обо¬ 
их случаях индекс должен содержать все кадры или блоки (то есть не должны при¬ 
меняться косвенные блоки, как в ІЖІХ). Таким образом, хранение в оперативной 
памяти 13 500 8-байтовых элементов (4 байта для дискового адреса, 1 байт для раз¬ 
мера кадра и 3 байта для номера начального кадра) против 216 000 5-байтовых эле¬ 
ментов (только дисковые адреса и размер) позволит сэкономить почти 1 Мбайт 
ОЗУ при воспроизведении фильма. 
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В результате вышеописанных соображений возникают следующие области воз¬ 
можных компромиссных решений: 

1. Кадровый индекс: большие расходы ОЗУ при воспроизведении фильма; 
меньшие потери дискового пространства. 

2. Блочный индекс (без расщепления кадров по блокам): меньшие потребнос¬ 
ти в ОЗУ; большие потери дискового пространства. 

3. Блочный индекс (с расщеплением кадров по блокам): меньшие потребности 
в ОЗУ; нет потерь дискового пространства; лишние перемещения головок. 

Компромиссные параметры представляют собой использование ОЗУ при вос¬ 
произведении фильма, постоянные потери дискового пространства и снижение 
производительности в результате лишних операций перемещения головок во вре¬ 
мя воспроизведения. Однако существуют различные методы решения данных про¬ 
блем. Использование ОЗУ может быть уменьшено при помощи выгрузки на диск 
части таблицы кадров. Перемещения головок при передаче кадра можно скрыть 
с помощью достаточного буферирования, хотя для этого потребуются дополни¬ 
тельная оперативная память и, возможно, дополнительные операции копирования. 
В хорошо продуманной системе следует тщательно проанализировать все эти фак¬ 
торы и сделать правильный выбор для конкретного приложения. 

Еще один фактор связан с тем, что использование способа хранения файла, 
показанного на рис, 7.17, а , усложняется необходимостью поиска непрерывной 
последовательности свободных блоков нужной длины. В идеале такая последо¬ 
вательность блоков не должна пересекать границу дорожек диска, хотя при ис¬ 
пользовании перекоса головок потери будут невелики. Тем не менее пересечения 
границы цилиндров следует избегать. Такое требование означает, что свободное 
дисковое пространство должно быть организовано скорее в виде списка незаня¬ 
тых участков диска переменного размера, нежели в виде простого списка свобод¬ 
ных блоков или битового массива (оба эти метода могут использоваться в вариан¬ 
те на рис. 7.17, б). 

Следует также отметить, что во всех случаях необходимо размещать блоки или 
кадры фильма по возможности близко друг от друга, например в пределах не¬ 
скольких дисковых цилиндров. При таком расположении потребуется меньшее ко¬ 
личество операций перемещений головок, в результате чего у сервера останется 
больше времени для других задач (не являющихся задачами реального времени) 
или для поддержки дополнительных видеопотоков. Подобное требование может 
быть удовлетворено при помощи разбиения диска на группы цилиндров, для 
каждой из которых будет поддерживаться отдельный список или битовый массив 
свободных блоков. Например, при учете свободных непрерывных участков дис¬ 
ка можно поддерживать один список для свободных участков диска размером 
в 1 Кбайт, один для 2-килобайтных участков, еще один для участков размером 
от 3 до 4 Кбайт, следующий — для участков размером от 5 до 8 Кбайт и т. д. При 
этом программа сможет легко найти свободный участок диска нужного размера. 

Другое различие между этими двумя подходами заключается в буферизации. 
При использовании блоков маленького размера при каждой операции чтения счи¬ 
тывается ровно один кадр. Соответственно, простая стратегия двойной буфериза- 
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ции хорошо работает: один буфер для воспроизведения текущего кадра и один для 
считывания следующего. При использовании фиксированных буферов каждый 
буфер должен быть достаточно большим, чтобы вместить самый большой І-кадр. 
С другой стороны, при динамическом выделении буфера для чтения каждого 
кадра и размере кадра, известном до операции чтения, для Р-кадров и В-кадров 
может выделяться буфер меньшего размера. 

При блоках большого размера требуется более сложная стратегия, так как каж¬ 
дый большой блок содержит несколько кадров, возможно, включая фрагменты 
кадров в конце каждого блока (в зависимости от выбранного варианта). Если для 
отображения или передачи кадров требуется, чтобы кадры были непрерывными, 
они должны копироваться, но копирование представляет собой дорогую операцию, 
которой следует по возможности избегать. Если непрерывность не требуется, то 
кадры, расположенные в двух блоках, могут передаваться по сети или на устрой¬ 
ство воспроизведения двумя порциями. 

При использовании больших блоков двойная буферизация может также при¬ 
меняться, но резервирование буферов для двух больших блоков приведет к боль¬ 
шим расходам оперативной памяти. Один способ решения этой проблемы за¬ 
ключается в использовании (для каждого потока) циклического буфера передачи, 
размерами слегка превосходящего размеры дискового блока, из которого инфор¬ 
мация передается на дисплей или в сеть. Когда количество полезной информации 
в буфере снижается до некой пороговой величины, с диска считывается следую¬ 
щий большой блок, его содержимое копируется в буфер передачи, а большой буфер 
блока возвращается в общий пул. Размер циклического буфера передачи должен 
быть выбран так, чтобы при достижении данными пороговой отметки в нем было 
достаточно места для другого полного дискового блока. Прямое чтение с диска 
в циклический буфер передачи невозможно, так как данные в нем располагаются 
как бы по кругу. Таким образом, копирование данных и использование оператив¬ 
ной памяти представляют собой компромиссный вариант. 

Еще одним фактором сравнения двух подходов является производительность 
диска. При использовании больших дисковых блоков диск работает на полной 
скорости, что часто является главной заботой разработчиков. Чтение маленьких 
Р-кадров и В-кадров по отдельности неэффективно. Кроме того, возможно хра¬ 
нение больших дисковых блоков на чередующихся наборах дисков (описывалось 
в главе 5), тогда как подобная операция с отдельными кадрами не имеет смысла. 

Вариант с использованием маленьких дисковых блоков (см. рис. 7.17, а) иногда 
называют постоянным шагом времени, так как каждый указатель индекса соот¬ 
ветствует равному количеству миллисекунд фильма. Вариант с использованием 
больших дисковых блоков (см. рис. 7.17, б), напротив, иногда называют постоян¬ 
ным шагом данных, так как блоки данных имеют равную длину. 

Еще одно отличие в этих двух подходах к организации файлов состоит в том, 
что если типы кадров хранятся в индексе (см. рис. 7.17, а), становится возможной 
быстрая перемотка при помощи отображения только І-кадров. Однако, в зависимо¬ 
сти от частоты присутствия І-кадров в потоке, скорость перемотки может воспри¬ 
ниматься либо как слишком быстрая, либо как слишком медленная. В любом слу¬ 
чае, при использовании файловой организации, показанной на рис. 7.17, 5, такой 
способ быстрой перемотки невозможен. При последовательном чтении файла для 
выборки требуемых кадров требуется большой объем операций ввода-вывода. 
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Второй подход заключается в использовании специального файла, воспроиз¬ 
ведение которого с нормальной скоростью создает иллюзию перемотки с удесяте¬ 
ренной скоростью. Этот файл может быть структурирован так же, как и другие 
файлы, с использованием либо кадрового, либо блочного индекса. При открытии 
файла система должна быть способна быстро находить файл быстрой перемот¬ 
ки. Когда пользователь нажимает кнопку быстрой перемотки, система должна 
мгновенно найти и открыть файл быстрой перемотки и прыгнуть в правильное 
место в этом файле. Ей известен номер текущего кадра, по которому, зная коэф¬ 
фициент ускорения файла быстрой перемотки, система может вычислить номер 
кадра в этом файле. 

При использовании кадрового индекса кадры находятся просто по индексу. 
При использовании блочного индекса требуется дополнительная информация 
в каждом элементе для идентификации кадра, содержащегося в блоке. Кроме того, 
требуется выполнение операции двоичного поиска в блочном индексе. Быстрая 
перемотка назад работает аналогично быстрой перемотке вперед. 


Размещение файлов для «почти видео по заказу» 


До сих пор мы рассматривали стратегии размещения файлов для видео по заказу. 
Для «почти видео по заказу» более эффективной оказывается другая стратегия. 
Как вы помните, один и тот же фильм передается в виде нескольких потоков. Даже 
если фильм хранится в виде непрерывного файла, для каждого потока требуется 
перемещение блока головок. Для устранения почти всех подобных операций по¬ 
иска цилиндра была разработана специальная стратегия файлового размеще¬ 
ния [63]. Использование этой стратегии проиллюстрировано на рис. 7.18 на при¬ 
мере фильма, передаваемого с частотой 30 кадров в секунду, с создаваемым каждые 
5 мин новым потоком, как в случае на рис. 7.14. При этих параметрах для 2-часо- 
вого фильма требуется 24 потока. 
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Рис. 7.18. Оптимальное размещение кадров на диске для «почти видео по заказу» 

При таком размещении наборы по 24 кадра объединяются и записываются на 
диск в виде одной записи. Они также могут быть считаны в виде одной записи. 
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Рассмотрим момент, в который поток 24 только что стартовал. Ему будет нужен 
кадр 0. Потоку 23, начавшемуся на 5 мин раньше, требуется кадр 9000. Потоку 22 
требуется кадр 18 000 и т. д., до потока 0, которому нужен кадр 207 000. Поместив 
эти кадры на диск именно в таком порядке, видеосервер может удовлетворить тре¬ 
бования 24 потоков в обратном порядке всего за одну операцию перемещения бло¬ 
ка головок диска. Конечно, кадры могут храниться на диске в обратном порядке, 
если есть смысл в обслуживании потоков в восходящем порядке. После того как 
последний поток был обслужен, головка диска может переместиться на дорожку 2, 
чтобы приготовиться к чтению следующей порции кадров. Такая схема не требует 
непрерывности всего файла и тем не менее позволяет получить хорошую произ¬ 
водительность для нескольких потоков сразу. 

Простая стратегия буферизации также заключается в использовании двойного 
буферирования. В то время пока данные из одного буфера передаются в 24 пото¬ 
ка, загружается другой буфер. Когда данные из первого буфера переданы, два бу¬ 
фера меняются местами. 

Интересный вопрос состоит в том, насколько большим сделать буфер. Очевид¬ 
но, он должен вмещать 24 кадра. Однако поскольку у кадров различный размер, 
верный выбор буфера является нетривиальным делом. Зарезервировать буфер 
размера, достаточного для вмещения 24 І-кадров, будет чрезмерным, однако если 
рассчитать размер буфера так, чтобы в него помещалось 24 средних кадра, то будет 
существовать постоянная опасность, что этого буфера не хватит. 

К счастью, для каждого конкретного фильма максимальный размер дорожки 
(в смысле рис.7.18) можно сосчитать заранее и выбрать буфер точно такого разме¬ 
ра. Однако может случиться, что в дорожке максимального размера будет 16 І-кад¬ 
ров, тогда как следующая по размеру дорожка будет содержать всего 9 І-кадров. 
Возможно, более разумная стратегия заключается в выборе буфера по второй по 
размеру дорожке. Такая стратегия означает усечение самой большой дорожки при 
игнорировании одного кадра для некоторых потоков. Чтобы избежать мелькания, 
можно повторять отображение предыдущего кадра. Никто этого не заметит. 

Если продолжить эту идею, еще лучше, возможно, остановиться на размере тре¬ 
тьей по величине дорожки, таким образом, используя буфер, способный вместить, 
скажем, 4 І-кадра и 20 Р-кадров. Повтор двух кадров в 2-часовом фильме, возмож¬ 
но, будет вполне приемлемым. До какого предела можно развивать данную идею? 
Вероятно до того момента, когда буфер сможет вмещать около 99 % всех доро¬ 
жек с кадрами. В данном случае мы получаем выбор между необходимым объе¬ 
мом оперативной памяти и качеством демонстрации фильма. Следует заметить, 
что чем больше потоков одновременно передает видеосервер, тем лучше окажутся 
статистические показатели и тем более однородным окажется набор кадров. 

Размещение нескольких файлов на одном диске 

До сих пор рассматривался вопрос размещения на диске одного фильма. Конечно, 
на видеосервере должно храниться одновременно несколько фильмов. При слу¬ 
чайном расположении файлов на диске для перемещения блока головок с одного 
фильма на другой потребуется много времени. 
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С этой проблемой можно бороться, принимая в расчет популярность фильмов 
при размещении их на диске. И хотя мало что может быть сказано о популярности 
отдельных фильмов (кроме как отметить, что на нее, вероятно, влияют имена 
суперзвезд), кое-что все-таки можно сказать об относительной популярности 
фильмов вообще. 

Разнообразные оценки популярности видеокассет в пунктах проката, библиотеч¬ 
ных книг, \ѵеЬ-страниц и даже используемых английских слов в рассказах обнару¬ 
живают, что популярность достаточно точно следует определенной закономерно¬ 
сти. Эта закономерность была обнаружена гарвардским профессором лингвистики 
Джорджем Ципфом (1902—1950) и называется теперь законом Ципфа. Закон 
утверждает, что если выстроить элементы (видеокассеты, книги, \ѵеЬ-страницы 
и т. д.) по порядку их популярности, то вероятность того, что следующий клиент 
выберет к -й элемент списка, примерно равна С/к , где С — нормирующая константа. 

Таким образом, частоты попаданий в тройку лидеров составляют соответствен¬ 
но С/1, С/2 и С/3, где С вычисляется так, чтобы сумма всех слагаемых была рав¬ 
на 1. Другими словами, при N фильмах получим: 

С/1 + С/2 + С/3 + С/4 + ... + С/ЛГ- 1. 

Из этого уравнения можно определить значение С. Для наборов из 10,100,1000 
и 10 000 элементов эти значения соответственно равны 0,341, 0,193, 0,134 и 0,102. 
Например, для 1000 фильмов частоты пяти самых популярных фильмов равны 
0,134, 0,067, 0,045, 0,034 и 0,027. 

Закон Ципфа проиллюстрирован на рис. 7.19. В данном случае мы решили 
продемонстрировать его силу на численности населения 20 крупнейших городов 
США. Согласно закону Ципфа, численность населения второго по величине горо¬ 
да должна быть приблизительно в два раза ниже, чем у самого крупного города, 
в третьем по величине городе должно жить около трети от численности населения 
самого крупного города 1 и т. д. Хотя и не идеально, но удивительно точно кривая, 
описывающая закон Ципфа, ложится рядом с точками на графике. 

Для фильмов, хранящихся на видеосервере, закон Ципфа утверждает, что са¬ 
мый популярный фильм будут брать в два раза чаще, чем второй по популярнос¬ 
ти, в три раза чаще, чем третий и т. д. Хотя поначалу кривая распределения частот 
стремительно убывает, у нее довольно длинный «хвост». Например, популярность 
50-го фильма составляет С/50, а популярность 51-го фильма — С/51, что означа¬ 
ет всего 2-процентное отличие в популярности между 50-м и 51-м фильмами. 
Чем дальше мы будем продвигаться по «хвосту» кривой, тем меньшим будет 
относительное различие между популярностью соседних фильмов. Из этого мож¬ 
но сделать вывод, что на видеосервере необходимо хранить довольно большое 
количество фильмов, так как спрос на фильмы за пределами 10 самых популяр¬ 
ных достаточно значителен. 

Зная относительную популярность различных фильмов, можно смоделировать 
производительность видеосервера и использовать эту информацию для размеще- 

1 Для справки: Нью-Йорк (1990) 7 322 564; Лос-Анджелес (1994) 3 620 543; Чикаго (1992) 2 832 901 
жителей. — ГІримеч. перев. 
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ния файлов. Изучения показали, что наилучшая стратегия на удивление проста 
и не зависит от распределения частот. Эта стратегия называется органным алго¬ 
ритмом ([140, 361]). Он заключается в размещении наиболее популярных филь¬ 
мов в середине диска, второго и третьего в хит-параде фильмов по обеим сторонам 
от самого популярного. Затем располагаются четвертый и пятый фильмы и т. д., 
как показано на рис. 7.20. Такое расположение файлов лучше всего работает, если 
каждый фильм представляет собой непрерывный файл того типа, который пока¬ 
зан на рис. 7.16, но также может, хотя и с меньшей эффективностью, применяться 
и для сегментированных файлов, расположенных в узком интервале соседних 
цилиндров диска. Название алгоритма происходит от того, что гистограмма час¬ 
тот напоминает слегка скособоченный орган. 



Рис. 7. 1 9. Кривая закона Ципфа для N = 20 



Цилиндр 


Рис. 7.20. Органное распределение файлов на видеосервере 
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Таким образом, этот алгоритм пытается удерживать головку диска посреди дис¬ 
ка. При 1000 фильмах по закону Ципфа вероятность заказа одного из пяти наибо¬ 
лее популярных фильмов составит 0,307. Это означает, что примерно 30 % време¬ 
ни блок головок будет находиться над цилиндрами, содержащими пятерку самых 
популярных фильмов, что удивительно много при 1000 фильмах на диске. 


Размещение файлов на нескольких дисках 

Для достижения более высокой производительности на видеосерверах часто ис¬ 
пользуется несколько дисков, работающих параллельно. Иногда используются 
чередующиеся наборы КАШ, но не часто, так как в общем случае система КАЮ 
предоставляет более высокую надежность за счет производительности. Видеосер¬ 
верам, как правило, требуется высокая производительность, и они обычно не силь¬ 
но заботятся об исправлении временных ошибок. К тому же контроллеры КАЮ 
могут стать узким местом системы, если им придется поддерживать одновремен¬ 
ную работу большого числа дисков. 

Более распространенная конфигурация представляет собой просто большое 
количество дисков, иногда называемое дисковой фермой. Эти диски не вращают¬ 
ся синхронно и не содержат битов четности, как диски КАЮ-систем. Одна возмож¬ 
ная конфигурация заключается в помещении фильма А на диск 1, фильма В на 
диск 2 и т. д., как показано на рис. 7.21, а. На практике современные диски могут 
вмещать по нескольку фильмов. 
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Рис. 7.21. Четыре способа организации мультимедийных файлов на нескольких дисках: 
без чередования (а); с одинаковым чередованием для всех файлов (б); в шахматном 
порядке (в); со случайным чередованием (г) 
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Такая организация проста в реализации и обладает не очень высокой надеж¬ 
ностью: если один диск выйдет из строя, все фильмы на дисковой ферме станут 
недоступны. Обратите, однако, внимание, что потеря диска с фильмами не идет 
ни в какое сравнение с потерей диска с какой-либо базой данных, так как фильмы 
можно легко снова записать на запасной диск с ОѴО. Недостаток такого подхода 
заключается в том, что нагрузка на диски может оказаться неравномерной. Если 
на одних дисках будут храниться фильмы, пользующиеся большим спросом, а на 
других дисках — менее популярные фильмы, эффективность системы окажется 
низкой. Конечно, при известной частоте запросов к фильмам можно переместить 
некоторые из них на другие диски, чтобы сбалансировать нагрузку. 

Второй вариант организации заключается в том, что каждый фильм распреде¬ 
ляется по нескольким дискам (рис. 7.21, б). Предположим, что все кадры имеют 
один и тот же размер (то есть несжатые кадры). Фиксированное число байтов 
фильма Л пишется на диск 1, затем такое же количество байтов записывается на 
диск 2 и т. д., до последнего диска (элемент ЛЗ). Затем элемент Л4 чередующегося 
набора снова пишется на диск 1 и т. д., пока не будет записан весь файл. Затем на 
те же диски таким же образом пишутся фильмы В, С и Б. 

Возможный недостаток такого подхода — поскольку все фильмы начинаются 
на первом диске, нагрузка на диски может оказаться несбалансированной. Один 
из способов более равномерного распределения нагрузки между дисков состоит 
в перемешивании стартовых дисков в шахматном порядке (рис. 7.21, е). Еще одна 
попытка сбалансировать нагрузку заключается в использовании случайного чере¬ 
дования фильмов по дискам (рис. 7.21, г). 

До сих пор мы предполагали, что все кадры имеют одинаковый размер. Для 
фильмов в формате МРЕС-2 такое предположение является неверным: І-кадры 
значительно превосходят Р-кадры. С этой проблемой можно бороться двумя спо¬ 
собами: покадровым чередованием и поблочным чередованием. При покадровом 
чередовании первый кадр фильма Л пишется на диск 1 в виде непрерывного фраг¬ 
мента, независимо от его размеров. Следующий кадр записывается на диск 2 и т. д. 
Фильм В распределяется по дискам таким же способом, начинаясь либо на том же 
диске, либо на следующем (при шахматном порядке), либо на случайном диске. 
Поскольку считываются кадры по одному, такое чередование не ускоряет счи¬ 
тывание одного отдельно взятого фильма. Однако при этом нагрузка распределя¬ 
ется по дискам лучше, чем на рис. 7.21, а, где эффективность может оказаться до¬ 
вольно низкой, если много зрителей захотят одновременно смотреть фильм Л, но 
никто не захочет смотреть фильм С. В целом распределение нагрузки по несколь¬ 
ким дискам позволяет лучше использовать общую пропускную способность дисков, 
тем самым давая возможность увеличить количество обслуживаемых одновремен¬ 
но клиентов. 

Другой вариант состоит в поблочном чередовании. Каждый фильм разбивает¬ 
ся на блоки фиксированного размера, которые и записываются последовательно 
(или в случайном порядке) на каждый диск. Каждый блок содержит один или бо¬ 
лее кадров или фрагментов кадров. В таком случае система может давать запросы 
на одновременное считывание нескольких блоков одного фильма. В результате 
каждого запроса данные считываются в разные буферы памяти, но таким образом, 
что после выполнения всех запросов в оперативной памяти собирается непрерыв- 
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ный фрагмент фильма (содержащий несколько кадров). Эти запросы могут обра¬ 
батываться параллельно. При удовлетворении последнего запроса запрашиваемо¬ 
му процессу может быть подан сигнал о том, что работа завершена. После этого 
процесс может передать эти данные пользователю. Несколько кадров спустя, ког¬ 
да в буфере останутся несколько последних кадров, издаются следующие запросы 
на чтение новых данных в другом буфере. При таком подходе под буферы использу¬ 
ется большое количество памяти, чтобы поддерживать диски в постоянно работаю¬ 
щем состоянии. В системе с 1000 активных пользователей и 1-мегабайтными буфе¬ 
рами (например, с использованием 256-килобайтных блоков на каждом из четырех 
дисков) для буферов требуется 1 Гбайт ОЗУ. Для видеосервера с 1000 пользова¬ 
телями такая величина — просто семечки, и она не должна стать проблемой. 

Последний вопрос, касающийся чередования, заключается в том, сколько дис¬ 
ков должно входить в чередующийся набор. Например, при 2-гигабйатных филь¬ 
мах и 1000 дисках на каждый диск может быть записан блок в 2 Мбайт, таким об¬ 
разом, ни один фильм не будет дважды использовать один и тот же диск. Другая 
крайность заключается в разбиении дисков на небольшие группы (как на рис. 7.21), 
когда каждый фильм распределяется по дискам внутри одной группы. Первый 
вариант, называемый широким чередованием, хорошо распределяет нагрузку по 
дискам. Основной его недостаток состоит в том, что в случае выхода из строя хотя 
бы одного диска ни один фильм не может демонстрироваться. Недостатком вто¬ 
рого варианта, называемого узким чередованием, является неравномерность по¬ 
пулярности фильмов, зато потеря одного диска разрушит фильмы только в одной 
небольшой группе дисков. Чередующиеся наборы с кадрами переменных разме¬ 
ров детально анализируются в [300]. 


Кэширование 

Традиционные алгоритмы удаления из кэша наиболее давно использовавшихся 
элементов, называемые также алгоритмами ЫШ-кэширования (ГеазТ-КесепіІу- 
Нзесі — с наиболее давним использованием), плохо годятся для работы с мульти¬ 
медийными файлами, так как характеристики доступа для мультимедийных и тек¬ 
стовых файлов различаются. Идея традиционных алгоритмов ПШ-кэширования 
заключается в том, что после использования блока он хранится в кэше на случай, 
если этот блок вскоре снова понадобится. Например, при редактировании файла 
набор блоков, в которых хранится файл, используется снова и снова, пока не будет 
завершен сеанс редактирования файла. Другими словами, если имеется относитель¬ 
но высокая вероятность повторного использования блока в течение короткого ин¬ 
тервала времени, этот алгоритм стоит использовать, чтобы избежать необходимо¬ 
сти обращения к диску в будущем. 

В мультимедиа обычный рисунок доступа к файлу таков, что фильм просмат¬ 
ривается последовательно от начала до конца. Повторно блоки используются ред¬ 
ко (только когда пользователь перематывает фильм, чтобы второй раз посмотреть 
какую-либо сцену). Следовательно, обычная техника кэширования не работает. 
Тем не менее в мультимедиа кэширование может применяться, но оно должно ис¬ 
пользоваться по-другому. В следующих разделах мы рассмотрим технику кэширо¬ 
вания в мультимедиа. 
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Блочное кэширование 

Хотя простое хранение блока на всякий случай не имеет смысла в мультимедиа, 
но предсказуемость поведения мультимедийных систем может быть использова¬ 
на для применения кэширования. Предположим, что два пользователя смотрят 
один и тот же фильм, причем один из них начал просмотр на 2 с позже другого. 
После того как первый пользователь получил и просмотрел некий блок, весьма 
вероятно, что спустя 2 с этот блок понадобится другому пользователю. Система 
легко может отличить фильмы, просматриваемые только одним зрителем, от филь¬ 
мов, у которых много зрителей, с близко расположенными друг другу точками вос¬ 
произведения. 

Таким образом, в данной ситуации возникает возможность сохранять в кэше 
блоки первого зрителя, так как с большой вероятностью они понадобятся второму 
зрителю. Хранить эти блоки в кэше или не хранить, зависит от времени хранения 
и наличия свободной памяти. Вместо хранения в кэше всех блоков диска подряд 
и удаления из кэша наиболее давно использовавшегося блока должна использо¬ 
ваться совершенно другая стратегия. Каждый фильм, у которого имеется второй 
зритель, расположенный в пределах интервала времени АТ от первого зрителя, дол¬ 
жен помечаться как фильм, для которого возможно кэширование и все его блоки 
должны сохраняться в кэше до тех пор, пока их не просмотрит второй (и, возмож¬ 
но, третий) пользователь. Для остальных фильмов кэширование не выполняется. 

Эту идею можно развить. В некоторых случаях бывает возможно объединить 
два потока. Предположим, два пользователя смотрят один фильм с интервалом 
в 10 с. Удерживать блоки в кэше в течение 10с можно, но для этого требуется мно¬ 
го памяти. В качестве альтернативы может использоваться не совсем честный при¬ 
ем: синхронизовать эти два фильма. Этого можно добиться, если слегка изменить 
частоту кадров обоих фильмов. Идея проиллюстрирована на рис. 7.22. 

На рис. 7.22, а оба фильма передаются со стандартной для ИТ5С частотой 
1800 кадров в минуту. Поскольку пользователь 2 начал просмотр на 10 с позже, он 
так и продолжает отставать на эти 10 с весь фильм. Однако на рис. 7.22, б при 
появлении второго зрителя поток первого пользователя слегка притормажива¬ 
ется. Вместо 1800 кадров в минуту в течение следующих 3 мин фильм передается 
с частотой 1750 кадров в минуту. Через 3 мин этот поток передает кадр 5550. 
Кроме того, поток 2-го пользователя воспроизводится с частотой, увеличенной 
до 1850 кадров в минуту, и через 3 мин он также достигает кадра 5550. С этого 
момента оба потока продолжают передачу с нормальной скоростью. 

Во время выравнивания потоков скорость обоих потоков изменяется на 2,8 %. 
Маловероятно, что пользователи заметят это 1 . Однако, если это так важно, период 
синхронизации может быть увеличен. 

Альтернативный способ снижения скорости пользователя для объединения его 
потока с другим потоком заключается в том, чтобы предоставить пользователю 
возможность смотреть фильмы с рекламой, естественно, за меньшую плату, чем 
без рекламы. Пользователь также сможет выбирать категории рекламируемой про- 


1 2,8 % это чуть меньше четверти тона музыкального ряда. Если в фильме в момент изменения скорости 
(в любую сторону) будет играть музыка, что бывает довольно часто, то эффект будет заметен и весь¬ 
ма неприятен. — Примем, перев. 
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дукции, поэтому реклама будет не столь раздражающей, и вероятность согласия 
пользователя на ее показ будет выше. Изменяя количество, длительность и время 
показа рекламных роликов, можно синхронизировать потоки, расхождение кото¬ 
рых по времени значительно больше 10 с [187]. 
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Рис. 7.22. Два пользователя смотрят один и тот же фильм, рассинхронизированный 
на 10 с (а); объединение двух потоков в один (б) 


Файловое кэширование 

Кэширование может применяться в мультимедийных системах и другим образом. 
Из-за огромного размера большинства фильмов (2 Гбайт) видеосерверы часто не 
способны хранить все свои фильмы на жестком диске, поэтому они хранят их на 
ИУИ или на ленте. Когда требуется фильм, он всегда может быть скопирован на 
диск, но чтобы найти фильм и скопировать его на диск, требуется значительное 
время. Соответственно, большинство видеосерверов поддерживают дисковый кэш 
фильмов, пользующихся наибольшим спросом. Популярные фильмы целиком 
хранятся на жестких дисках. 
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Другой способ использования кэша состоит в хранении на жестком диске пер¬ 
вых нескольких минут каждого фильма. Таким образом, при запросе фильма вос¬ 
произведение может начинаться немедленно с файла на жестком диске. Тем вре¬ 
менем фильм копируется на жесткий диск с ОѴО пли ленты. Если каждый раз 
сохранять на жестком диске достаточный по размеру фрагмент фильма, вероят¬ 
ность того, что программа успеет скопировать следующий фрагмент, будет доволь¬ 
но высока. При этом считанный фрагмент будет попадать в кэш и оставаться на 
диске на тот случай, если он вдруг понадобится позднее. Если этот фильм окажет¬ 
ся невостребованным в течение долгого времени, он будет удален из кэша, чтобы 
освободить место для более популярных фильмов. 


Дисковое планирование в мультимедиа 

Мультимедиа накладывает на диски требования, отличные от требований тради¬ 
ционных текст-ориентированных приложений, таких как компиляторы или тек¬ 
стовые процессоры. В частности, мультимедиа требует исключительно высоких 
скоростей передачи данных и доставки данных в режиме реального времени. Ни 
одна из этих задач не является тривиальной. Более того, в случае видеосервера 
присутствует экономическое давление, нацеленное на то, чтобы один сервер одно¬ 
временно обслуживал тысячи клиентов. Эти требования накладывают отпечаток 
на всю систему. Выше была рассмотрена файловая система. Теперь познакомимся 
с планированием в мультимедийных системах. 

Статическое дисковое планирование 

Мультимедиа предъявляет ко всем частям системы повышенные требования по 
скорости передачи данных и доставке данных в режиме реального времени. В то 
же время у мультимедийных систем есть одно свойство, упрощающее управление 
этими системами. Таким свойством является предсказуемость. В традиционной 
операционной системе запросы к блокам диска поступают почти непредсказуемым 
образом. Лучшее, что может сделать дисковая подсистема, — это выполнить опе¬ 
режающее чтение по одному блоку для каждого открытого файла. В остальном ей 
остается лишь ожидать запросов и выполнять их по мере поступления. В мультиме¬ 
дийных системах все по-другому. Каждый активный поток накладывает на систему 
предсказуемую, строго определенную нагрузку. При воспроизведении фильма 
в формате БГГ5С каждые 33,3 мс каждому клиенту требуется следующий кадр из его 
файла, и у системы есть 33,3 мс, чтобы считать и переслать всем клиентам по кад¬ 
ру (система должна буферировать по крайней мере по одному кадру на каждый 
поток, чтобы при считывании кадра к+ 1 она могла параллельно передавать кадр к). 

Эта предсказуемость нагрузки может использоваться для планирования дис¬ 
ковых операций с помощью алгоритмов, специально скроенных для мультимедий¬ 
ных систем. Ниже мы рассмотрим всего один диск, но данный подход применим 
также и для нескольких дисков. В этом примере мы предположим, что имеется 
всего 10 пользователей, каждый из которых смотрит свой фильм. Более того, 
мы будем считать, что у всех фильмов одинаковое разрешение, частота кадров 
и другие характеристики. 
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В зависимости от системы на компьютере могут работать 10 процессов, по 
одному на видеопоток, или один процесс с 10 потоками, или даже один процесс 
с одним потоком, поочередно обрабатывающий 10 видеопотоков. Эти детали не 
важны. Важно лишь то, что время делится на раунды, то есть интервалы времени, 
равные длительности воспроизведения одного кадра (33,3 мс для ЫТ5С или 40 мс 
для РАЬ). В начале каждого раунда от имени каждого пользователя формируется 
дисковый запрос (рис. 7.23). 


Поток 



„ . „ 701 92 281 130 326 410 160 466 204 524 

Запрашиваемым блок 


Оптимизирующий алгоритм 


92 130 160 204 281 326 410 466 524 701 

Порядок обработки дисковых запросов - *~ 

Рис. 7.23. За один раунд каждый фильм запрашивает один кадр 

Получив к началу раунда все запросы, диск знает, что ему предстоит делать 
в течение этого раунда. Он также знает, что до начала следующего раунда никаких 
других запросов не поступит. Соответственно, он может сортировать запросы так, 
чтобы обрабатывать их оптимальным образом, возможно, в порядке цилиндров 
(хотя в некоторых случаях может использоваться обработка в порядке секторов). 
На рис. 7.23 запросы показаны отсортированными в порядке цилиндров. 

На первый взгляд может показаться, что подобная оптимизация дисковых опе¬ 
раций не нужна, так как до тех пор, пока диск успевает выполнять запросы в срок, 
не имеет значения, остается ли у него в запасе 1 мс или 10 мс. Однако подобное 
рассуждение является ошибочным. Оптимизация подобного рода позволяет снизить 
среднее время обработки каждого запроса, это означает, что диск может обрабо¬ 
тать большее число запросов за один раунд. Другими словами, подобная оптими¬ 
зация обработки дисковых запросов позволяет увеличить количество фильмов, од¬ 
новременно транслируемых видеосервером. Кроме того, оставшееся время в конце 
раунда также может быть использовано для обслуживания любых запросов, не яв¬ 
ляющихся запросами реального времени. 

Если у сервера слишком много потоков данных, время от времени он не будет 
успевать считывать кадры из удаленных уголков диска. Но пока такие неудачи 
будут редкими, с ними можно мириться, выигрывая в количестве одновременно 
обслуживаемых потоков данных. Обратите внимание, что для работы диска зна¬ 
чение имеет число потоков данных, а не число клиентов. Если несколько клиен¬ 
тов принимают один и тот же поток, это никак не влияет на производительность 
диска или на планирование дисковых операций. 
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Для поддержания равномерности поступления данных к клиентам на сервере 
должна использоваться двойная буферизация. Во время первого раунда исполь¬ 
зуется один набор буферов, по буферу на поток данных. Когда раунд завершен, 
выходной процесс или процессы разблокируются и начинают передавать первый 
кадр. В то же время поступают новые запросы на кадр 2 каждого фильма (для каж¬ 
дого фильма у процесса может быть по два потока: один для ввода с диска и один 
для вывода). Такая схема уменьшает количество дисковых операций вдвое за счет 
удвоения объемов оперативной памяти, занимаемой буферами. В зависимости от 
относительной доступности, производительности и стоимости операций ввода- 
вывода в памяти против дискового ввода-вывода может быть рассчитана и исполь¬ 
зована оптимальная стратегия. 

Динамическое дисковое планирование 

В приведенном выше примере предполагалось, что у всех потоков данных одина¬ 
ковое разрешение, частота кадров и другие характеристики. Отбросим теперь дан¬ 
ное предположение. Различные фильмы могут обладать различными скоростями 
передачи данных, поэтому нельзя разбивать время на раунды по 33,3 мс, за кото¬ 
рые для каждого потока считывается по кадру. Запросы к диску поступают более 
или менее случайно. 

Каждый дисковый запрос указывает номер блока, который должен быть про¬ 
читан, а также крайний срок выполнения этой операции. Для простоты будем пред¬ 
полагать, что фактическое время обслуживания каждого запроса одинаково (даже 
если на самом деле это не так). Таким образом, мы можем вычесть фиксированное 
время обслуживания каждого запроса из его конечного срока, чтобы получить 
крайний срок инициирования запроса. Такое предположение упрощает модель, так 
как планировщик дисков беспокоится о выполнении запросов в срок. 

При запуске системы дисковых запросов, ждущих обработки, нет. Когда при¬ 
ходит первый дисковый запрос, он обслуживается немедленно. При выполнении 
первой операции по поиску цилиндра могут поступить другие запросы, поэтому, 
когда первый запрос выполнен, у дискового драйвера может быть выбор, какой 
запрос обрабатывать следующим. Один из запросов выбирается и обслуживается. 
Когда этот запрос выполнен, у нас есть набор необслуженных запросов: те, что не 
были обслужены в первый раз плюс поступившие во время обработки второго за¬ 
проса. В общем случае после завершения обработки запроса у драйвера есть не¬ 
кий набор необработанных запросов, из которых он должен выбрать следующий. 
Вопрос звучит так: «Какой алгоритм следует использовать для выбора следующего 
запроса?» 

В выборе следующего дискового запроса играют роль два фактора: крайние 
сроки завершения и цилиндры. С точки зрения производительности сортировка 
запросов по цилиндрам и использование элеваторного алгоритма минимизируют 
время поиска цилиндра, но при этом запросы к крайним цилиндрам диска могут 
оказаться обслуженными с опозданием. С точки зрения задачи реального времени 
следует сортировать запросы по срокам выполнения. При этом минимизируется 
вероятность пропуска крайнего срока обработки запроса, но увеличивается суммар¬ 
ное время поиска. 
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Оба эти фактора учитываются алгоритмом зсап-ЕОР [273]. Основная идея это¬ 
го алгоритма заключается в объединении запросов, конечные сроки которых рас¬ 
положены близко на временной шкале, в пакеты и обработка этих пакетов в по¬ 
рядке цилиндров. Рассмотрим ситуацию на рис. 7.24 в момент времени і = 700. 
Дисковый драйвер знает, что у него есть 11 необработанных запросов к различным 
цилиндрам и с различными сроками выполнения. Он может, например, решить 
обрабатывать пять запросов с наименьшими сроками выполнения в виде одного 
пакета, отсортировать их по порядку цилиндров и использовать для их обработки 
элеваторный алгоритм. При этом порядок считываемых цилиндров будет следую¬ 
щим: 110, 330, 440, 676 и 680. До тех пор пока каждый запрос выполняется в срок, 
организация запросов может изменяться так, чтобы минимизировать требуемое 
время перемещения блока головок. 


Объединение Запросы (отсортированы по сроку выполнения) 



Срок выполнения (мс) —► 

Рис. 7.24. Обработка пакетов при помощи алгоритма зсап-ЕОР 

Когда у различных потоков различные скорости потоков данных, появление 
нового клиента вызывает серьезную проблему. Видеосервер должен принять ре¬ 
шение, может ли он себе позволить обслуживание еще одного пользователя. Если 
допуск нового клиента приведет к тому, что другие потоки данных станут часто 
пропускать свои критические сроки, то ответом клиенту, вероятно, должен быть 
отказ. Существует два метода принятия решения, разрешить ли подключение но¬ 
вого клиента. Один способ состоит в предположении, что каждому среднему кли¬ 
енту требуется определенное количество ресурсов, например пропускная способ¬ 
ность диска, буферы памяти, время центрального процессора и т. д. Если всех этих 
ресурсов достаточно для одного среднего клиента, то новый клиент получает раз¬ 
решение на просмотр фильма. 

Другой алгоритм учитывает большее количество деталей. Он изучает характе¬ 
ристики конкретного фильма, заказываемого клиентом, проверяя (заранее рас¬ 
считанные) скорость передачи данных для этого фильма, отличающуюся для чер¬ 
но-белых и цветных фильмов, мультипликационных и кинофильмов и даже для 
любовных историй и фильмов о войне. Мелодрамы обычно развиваются нетороп¬ 
ливо с долгими сценами и медленными наплывами кадров и поэтому отлично сжи¬ 
маются, тогда как в кинобоевиках много динамичных сцен и быстро сменяющих 
друг друга монтированных сцен, снятых с разных камер, поэтому в них много 
І-кадров и большие Р-кадры. Если у сервера достаточно мощностей для демон¬ 
страции конкретного фильма, заказываемого клиентом, тогда клиенту выдается 
разрешение на просмотр; в противном случае клиент получает отказ. 
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Исследования в области мультимедиа 

Мультимедиа находится сегодня в центре внимания, поэтому в этой области про¬ 
водится большое количество исследований. Большая часть этих исследований по¬ 
священа содержанию мультимедиа, инструментарию для создания мультимедиа 
и приложениям. Все эти темы выходят за пределы данной книги. Однако некото¬ 
рые из исследований касаются структуры операционной системы, либо созданию 
новой операционной системы [41], либо добавлению мультимедийной поддержки 
к существующей операционной системе [234]. Близкой темой исследований 
является разработка мультимедийных серверов [26, 153, 216, 362]. 

Некоторые статьи по мультимедийной тематике посвящены не новым сис¬ 
темам, а алгоритмам, применяемым в мультимедийных системах. Популярной 
темой является планирование центрального процессора реального времени для 
мультимедиа [18, 38, 83, 134, 167, 247, 364]. Другой освещаемой в статьях темой 
является планирование дисковых операций в мультимедийных системах [200,279, 
355]. Размещение файлов и управление нагрузкой на видеосерверах тоже представ¬ 
ляет собой важную тему исследований [123,300,343], как и объединение видеопо¬ 
токов для снижения необходимой пропускной способности [103]. 

В тексте обсуждалось влияние популярности фильмов на размещение файлов 
на видеосервере. Эта тема является областью продолжающихся исследований 
[34,138]. Наконец, безопасность и конфиденциальность в мультимедиа (например, 
на видеоконференциях) также представляют интерес для исследователей [6,157]. 


Резюме 

Мультимедиа представляет собой развивающуюся область применения компью¬ 
теров. Из-за больших размеров мультимедийных файлов и требований реального 
времени по их доставке операционные системы, разработанные для работы с тек¬ 
стом, не являются оптимальными для мультимедиа. Мультимедийные файлы 
состоят из большого количества параллельных дорожек: как правило, одной ви¬ 
деодорожки и по крайней мере одной звуковой дорожки, иногда также дорожки 
субтитров. Все эти дорожки должны синхронизироваться при воспроизведении. 

Звук записывается при помощи периодического измерения уровня мощности, 
обычно с частотой 44 100 отсчетов в секунду (для качества звука компакт-диска). 
К звуковому сигналу может быть применена компрессия, позволяющая уменьшить 
размеры данных примерно в 10 раз. Для сжатия видеоинформации применяется 
как внутрикадровое сжатие ^РЕС), так и межкадровое сжатие (МРЕС). Послед¬ 
ний алгоритм представляет Р-кадры в виде разностей относительно предыдущего 
кадра. В алгоритме МРЕС также используются В-кадры, базирующиеся либо на 
предыдущем, либо на последующем кадре. 

Для мультимедиа необходимо планирование реального времени, ставящее 
целью выполнение определенных задач в указанные сроки. Широкое распрост¬ 
ранение получили два алгоритма. Первый из них является алгоритмом плани¬ 
рования КМ5. Он представляет собой статический алгоритм с прерываниями, на¬ 
значающий процессам фиксированные приоритеты, основываясь на их периодах. 
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Второй (ЕОЕ) представляет собой динамический алгоритм, всегда выбирающий 
задание с ближайшим предельным сроком выполнения. Алгоритм ЕОР более 
сложен, но позволяет достичь 100-процентного использования процессорного 
времени, что недоступно для алгоритма КМ 5. 

В мультимедийных файловых системах используется, как правило, модель 
«толкания» данных от сервера, а не «вытягивания» их клиентом. Как только 
поток запущен, биты поступают с диска без дальнейших запросов пользователя. 
Такой подход, радикально отличающийся от применяемого в традиционных опе¬ 
рационных системах, необходим для выполнения требований реального времени. 

Для хранения мультимедийных данных могут использоваться как непрерыв¬ 
ные, так и сегментированные файлы. В последнем случае непрерывный сегмент 
файла может иметь переменную длину (один блок представляет собой один кадр) 
или фиксированную длину (один блок содержит несколько кадров). У обоих под¬ 
ходов есть свои преимущества и недостатки. 

Размещение файлов на диске влияет на производительность. При наличии не¬ 
скольких файлов на одном диске иногда применяется органный алгоритм. Рас¬ 
пространены и чередующиеся наборы файлов (широкие и узкие) на нескольких 
дисках. Для увеличения производительности также широко применяется блочное 
и файловое кэширование. 


Вопросы 

1. Чему равна скорость передачи данных для несжатого полноцветного ХСА- 
монитора, воспроизводящего 25 кадров в секунду? Может ли такой поток 
поступать с ІЛіга\УісІе 5С5І-диска? 

2. Может ли несжатый черно-белый телевизионный сигнал формата ЫТ5С 
передаваться по быстрой сети ЕіЬегпеІ? Если да, то сколько каналов одно¬ 
временно? 

3. Горизонтальное разрешение системы РГОТѴ вдвое превышает обычное те¬ 
левидение (1280 вместо 640 пикселов). Учитывая информацию, приведен¬ 
ную в тексте, насколько большая пропускная способность требуется для те¬ 
левидения высокой четкости по сравнению со стандартным телевидением? 

4. На рис. 7.2 изображены отдельные файлы для быстрой перемотки вперед и 
назад. Если видеосервер должен также обеспечивать замедленное воспро¬ 
изведение в прямом направлении, требуется ли для этого отдельный файл? 
А для воспроизведения в обратном направлении? 

5. Компакт-диск может содержать 74 мин музыки или 650 Мбайт данных. 
Оцените коэффициент сжатия, используемый для музыки. 

6. При квантовании звуковой сигнал преобразуется в 16-разрядное число 
(один знаковый бит и 15 бит для амплитуды). Чему равен максимальный 
шум квантования в процентах? Представляет ли он большую проблему при 
записи концертов для флейты, чем для рок-н-рольных концертов, или эта 
проблема не зависит от музыкального жанра? Поясните свой ответ. 
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7. Звукозаписывающая студия может создать оригинальную запись, исполь¬ 
зуя 20-битовое квантование. Конечные потребители их продукта получат 
16-битовые данные. Предложите метод снижения эффекта шума квантова¬ 
ния и обсудите достоинства и недостатки вашей схемы. 

8. Оба формата телевизионных сигналов МТ5С и РАЬ используют канал веща¬ 
ния с полосой частот 6 МГц, в то же время стандарт МТ5С предусматривает 
передачу 30 кадров в секунду, тогда как РАЬ — только 25 кадров в секунду. 
Как эго возможно? Означает ли это, что при использовании одинаковой схе¬ 
мы кодирования цвета стандарт N750 имел бы лучшее качество, чем РАЬ? 
Аргументируйте свой ответ. 

9. В дискретном косинусном преобразовании используется блок 8x8, тогда как 
в алгоритме, применяемом для компенсации движения, используется блок 
16x16. Связаны ли с этим различием какие-либо проблемы, и если да, то как 
они решаются в стандарте МРЕС? 

10. На рис. 7.9 было показано, как алгоритм МРЕС работает при стационарном 
заднем плане и двигающемся актере. Рассмотрите ситуацию, в которой 
видеокамера установлена на треножник и снимает панораму, медленно пово¬ 
рачиваясь слева направо с такой скоростью, что никакие два последователь¬ 
ных кадра не являются одинаковыми. Должны ли все кадры быть І-кадрами? 
Поясните свой ответ. 

11. Предположим, что каждый из трех процессов на рис. 7.10 сопровождается 
процессом, поддерживающим поток аудиоданных, работающим с тем же 
периодом, что и видеопроцесс, так что буферы аудиоданных могут обнов¬ 
ляться в перерывах между видеокадрами. Все три аудиопроцесса идентич¬ 
ны. Сколько процессорного времени доступно для аудиопроцесса на каж¬ 
дом кадре? 

12. На компьютере работают два процесса реального времени. Первый процесс 
работает каждые 25 мс в течение 10 мс. Второй работает каждые 40 мс в те¬ 
чение 15 мс. Может ли алгоритм КМ5 управлять этими потоками? 

13. Загруженность центрального процессора видеосервера составляет 65 %. 
Сколько фильмов может демонстрировать такой видеосервер с помощью 
алгоритма планирования К.М5? 

14. На рис. 7.12 алгоритм ЕОЕ загружает центральный процессор на 100 % вплоть 
до момента времени I = 150. Он не может обеспечить 100-процентную загруз¬ 
ку центрального процессора бесконечно долго, так как в среднем в каждую 
секунду у алгоритма есть работы только на 975 мс. Продолжите нарисован¬ 
ный график за пределы 150 мс и определите, когда центральный процессор, 
наконец, в первый раз перейдет в состояние простоя. 

15. ОѴП может хранить достаточно данных для размещения на нем полномет¬ 
ражного фильма со скоростью передачи данных, достаточной для демонст¬ 
рации фильма качества телевидения. Почему бы не использовать просто 
«ферму» из нескольких ОѴО-дисководов в качестве источника данных 
видеосервера? 
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16. Оператор системы «почти видео по заказу» обнаружил, что в определенном 
городе зрители не хотят ждать начала фильма более 6 мин. Сколько парал¬ 
лельных потоков потребуется для 3-часового фильма? 

17. Рассмотрите систему, использующую схему Абрам—Профета и Шина, в кото¬ 
рой оператор видеосервера хочет предоставить клиентам возможность 
полностью локального поиска вперед и назад в течение 1 мин. Если пред¬ 
положить, что используется видеопоток МРЕС-2 со скоростью передачи 
данных 4 Мбит/с, сколько понадобится каждому клиенту памяти на локаль¬ 
ные буферы? 

18. Система видео по заказу ЕЮТѴ использует модель с маленькими блоками 
(см. рис. 7.17, а), с размером дисковых блоков 1 Кбайт. При разрешении ви¬ 
деоизображения 1280x720 и скорости передачи данных 12 Мбит/с сколько 
дискового пространства будет расходоваться на внутреннюю фрагмента¬ 
цию в 2-часовом фильме, если используется стандарт ЫТЗС? 

19. Рассмотрите схему хранения файлов, показанную на рис. 7.17, а, для стан¬ 
дартов ЫТ5С и РАЬ. Для заданных размеров блока и фильма есть ли разни¬ 
ца в потерях на внутреннюю фрагментацию для этих двух стандартов? Если 
да, то какой стандарт лучше и почему? 

20. Рассмотрите альтернативы, показанные на рис. 7.17. Обладает ли одна из 
двух систем преимуществом при переходе на НОТѴ? Обсудите. 

21. Схема видео по заказу Чена и Тапара лучше всего работает в том случае, 
когда все кадры имеют одинаковый размер. Предположим, что фильм одно¬ 
временно демонстрируется по 24 потокам и что каждый 10-й кадр является 
І-кадром. Также предположим, что І-кадры в 10 раз больше Р-кадров. В-кад- 
ры имеют тот же размер, что и Р-кадры. Чему равна вероятность того, что 
буфера, равного размеру 4 І-кадров и 20 Р-кадров, окажется недостаточно? 
Предположите, что кадры разных типов распределены в потоке случайным 
образом, независимо друг от друга. 

22. Конечный результат примера на рис. 7.15 заключается в том, что точка вос¬ 
произведения не находится более в середине буфера. Разработайте схему, 
гарантирующую 5 мин перед точкой воспроизведения и 5 мин после нее. Вы 
можете делать любые разумные предположения, но должны объявлять о них 
открыто. 

23. Схема на рис. 7.16 требует, чтобы все языковые дорожки читались при каж¬ 
дом кадре. Допустим, что разработчики видеосервера должны обеспечить 
поддержку большого числа языков, но не хотят выделять на них много опе¬ 
ративной памяти для буферов. Какие еще альтернативные методы возмож¬ 
ны в данной ситуации. Каковы достоинства и недостатки каждого метода? 

24. На маленьком видеосервере восемь фильмов. Чему равны вероятности зака¬ 
за самого популярного фильма, второго по популярности фильма и т. д. в со¬ 
ответствии с законом Ципфа? 

25. Для хранения 1000 30-секундных в формате МРЕС-2 видеоклипов, демонст¬ 
рируемых на скорости 4 Мбит/с, используется 14-гигабайтный диск с 1000 
цилиндрами. Какую часть времени будет проводить блок головок в 10 сред¬ 
них цилиндрах, учитывая закон Ципфа? 
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26. Если предположить, что относительный спрос на фильмы А, В, С и В опи¬ 
сывается законом Ципфа, то чему будет равно относительное использование 
четырех дисков (см. рис. 7.21) для показанных четырех методов чередования? 

27. Два клиента службы видео по заказу начали просмотр фильма в формате 
РАБ с интервалом 6 с. Если система для объединения этих двух потоков 
в один ускорит один поток и замедлит другой, какой процент ускорения/ 
замедления потребуется, чтобы объединить потоки через 3 мин? 

28. На видеосервере с фильмами в формате МРЕС-2 используется схема раун¬ 
дов (см. рис. 7.23) для видео в стандарте ЬТТБС. Все видеоданные считывают¬ 
ся с одного іЛіга\ѴісІе ЗСЗІ-диска со средним временем поиска, равным 3 мс. 
Сколько одновременных потоков может поддерживать такой видеосервер? 

29. Повторите предыдущее задание, но с предположением, что алгоритм зсап- 
ЕПР уменьшает среднее время поиска на 20 %. Сколько одновременных по¬ 
токов может поддерживать видеосервер теперь? 

30. Еще раз повторите предыдущее задание, но на этот раз предположите, что 
каждый кадр распределен по четырем дискам с алгоритмом зсап-ЕОЕ, умень¬ 
шаемым среднее время поиска на 20 % для каждого диска. Сколько одно¬ 
временных потоков может поддерживать видеосервер теперь? 

31. В тексте описывалось использование пакета из пяти дисковых запросов при 
планировании ситуации на рис. 7.24. Если обработка всех запросов занима¬ 
ет одинаковое количество времени, чему равно максимальное возможное 
время выполнения запроса в данном примере? 

32. Во многих растровых изображениях, применяемых для создания компью¬ 
терных «обоев», используется небольшое количество цветов, и такие изоб¬ 
ражения легко сжимаются. Простая схема компрессии состоит в следующем: 
выбирается значение данных, не используемое во входном файле, и исполь¬ 
зуется в качестве флага. Файл считывается побайтно, при этом ищутся по¬ 
вторяющиеся байты. Байты, встречающиеся в файле от одного до трех раз 
подряд, копируются в выходной файл без преобразований. Повторяющиеся 
по четыре и более раз байты заменяются флаговым байтом, за которым пи¬ 
шется счетчик байтов от 4 до 255 и сам байт данных. Напишите программу, 
использующую данный метод сжатия, а также программу декомпрессии, 
позволяющую восстановить исходный файл. Дополнительный балл: как вы 
поступите с файлами, содержащими флаговый байт среди данных? 

33. Компьютерная анимация реализуется с помощью отображения последова¬ 
тельности слегка отличающихся друг от друга изображений. Напишите 
программу, рассчитывающую побайтную разницу между двумя несжаты¬ 
ми растровыми изображениями одинакового размера. Выходной файл бу¬ 
дет такого же размера, как и входные файлы. Используйте полученный вы¬ 
ходной файл в качестве входного для программы сжатия из предыдущего 
задания и сравните эффективность этого подхода с непосредственным сжа¬ 
тием отдельных изображений. 
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С самого начала компьютерная промышленность была движима нескончаемым 
стремлением ко все большей и большей вычислительной мощности. Компьютер 
ЕЫІАС 1 (Еіесігоиіс Ыишегісаі Іп(;е§га(;ог апсі Саісиіаіог — электронный цифровой 
интегратор и калькулятор) мог выполнять 300 операций в секунду, что в 1000 раз 
превосходило скорость всех электромеханических калькуляторов того времени. 
Однако его колоссальной по тем временам мощности разработчикам показалось 
недостаточно. Теперь у нас есть машины в миллион раз мощнее, чем Е№ АС, одна¬ 
ко спрос на все большие мощности не стихает. Астрономы пытаются понять все¬ 
ленную, биологи бьются над расшифровкой генома человека, а инженеры хотят 
создать более надежные и экономичные самолеты. Всем им нужны компьютерные 
мощности. Сколько бы ни было доступно мощности на данный момент, ее всегда 
оказывается недостаточно. 

В прошлом решение всегда состояло в том, чтобы увеличить тактовую частоту 
процессора. К сожалению, сегодня мы приближаемся к некоторым фундаменталь¬ 
ным пределам тактовой частоты. В соответствии со специальной теорией относи¬ 
тельности Эйнштейна, никакой сигнал (в том числе электрический) не может рас¬ 
пространяться быстрее скорости света, равной 30 см/нс в вакууме и около 20 см/нс 
в медном проводе или оптоволоконном кабеле. Это означает, что в компьютере с 
тактовой частотой 10 Гц сигналы за один такт не могут распространяться дальше, 
чем на 2 см. Для 100-гигагерцового компьютера полная длина пути сигнала будет 
составлять максимум 2 мм. Компьютер с тактовой частотой 1 ТГц (1000 ГГц) дол¬ 
жен иметь размеры менее 100 мкм, чтобы сигнал от одного его конца до другого 
успел пройти за один такт процессора. 

Производство компьютеров такого размера может теоретически и возможно, но 
при этом мы сталкиваемся с другой фундаментальной проблемой: рассеянием теп¬ 
ла. Чем быстрее работает компьютер, тем больше тепловой энергии он производит, 
а чем меньше компьютер, тем труднее отводить эту тепловую энергию. Уже сейчас 
на новых системах с процессором Реиііиш вентилятор для охлаждения централь¬ 
ного процессора больше, чем сам центральный процессор. Для перехода с частоты 
1 МГц на частоту 1 ГГц требовалось всего лишь постепенное усовершенствование 


Построен в Великобритании в 1943 году. Долгое время считался первым компьютером в мире. 
Состоял из 18 000 электронных ламп и был 24 м в длину. — Примеч. перев. 
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технологии производства микросхем. Для перехода на частоту 1 ТГц потребуются 
более радикальные изменения. 

Другой способ увеличения вычислительной мощности системы состоит в ис¬ 
пользовании параллельных вычислений. Для этого могут использоваться многопро¬ 
цессорные компьютеры, состоящие из большого количества процессоров, каждый 
из которых работает с «нормальной» частотой (чтобы это ни означало в данном 
году). Однако совместно эти процессоры обладают значительно большей мощно¬ 
стью, чем отдельный центральный процессор. В настоящее время серийно выпус¬ 
каются и продаются системы с 1000 процессорами. В ближайшее десятилетие, ве¬ 
роятно, будет построена система с 1 млн процессоров. Хотя существуют и другие 
возможные методы увеличения скорости вычислений, например биологические 
компьютеры, в данной главе мы сконцентрируем наше внимание на системах, со¬ 
стоящих из большого числа обычных центральных процессоров. 

Высокопараллельные компьютеры часто применяются для сложных вычисле¬ 
ний. Такие задачи, как прогноз погоды, моделирование воздушного потока вокруг 
крыла самолета, мировой экономики или взаимодействия лекарства с рецептором 
в мозгу, требуют больших компьютерных мощностей. Для решения этих задач 
требуются долгие расчеты на большом количестве центральных процессоров од¬ 
новременно. Многопроцессорные системы, обсуждаемые в данной главе, широко 
применяются для данных и подобных задач в науке и машиностроении, а также 
в других областях. 

Еще один способ увеличения вычислительной мощности системы заключает¬ 
ся в использовании параллельных расчетов на большом количестве отдельных 
компьютеров, соединенных в локальную или глобальную сеть. В настоящее время 
продолжается быстрый рост глобальной сети Интернет. Изначально эта сеть со¬ 
здавалась как прототип помехоустойчивой военной системы управления, затем она 
стала популярной среди ученых кибернетиков, а в последние годы Интернетом 
начали пользоваться самые широкие слои населения. Не так давно Интернет полу¬ 
чил еще одно применение: поскольку он связывает по всему миру тысячи компью¬ 
теров, было решено использовать эту сеть для решения больших научных проблем. 
С точки зрения вычислительной мощности система, состоящая из 1000 компью¬ 
теров по всему миру, не отличается от такой же системы из 1000 компьютеров, сто¬ 
ящих в одном помещении, хотя характеризуется задержкой и имеет некоторые 
другие технические характеристики. Такие системы также будут рассматриваться 
в данной главе. 

Поместить 1 млн не связанных друг с другом компьютеров в одну комнату дос¬ 
таточно легко при условии, что у вас достаточно денег и достаточно большая комна¬ 
та. Разместить 1 млн не связанных друг с другом компьютеров по всему миру еще 
легче, поскольку не нужно искать большого помещения. Проблемы начинаются, 
когда вам требуется соединить эти компьютеры друг с другом для решения одной 
общей задачи. Поэтому была проведена большая работа в области технологии меж¬ 
компьютерных соединений, а различные технологии привели к появлению качествен¬ 
но отличных типов систем и различной организации программного обеспечения. 

Весь обмен информацией между электронными (или оптическими) компонен¬ 
тами сводится, в конечном итоге, к отправке и приему сообщений, представляю¬ 
щих собой строго определенные последовательности битов. Различия состоят во 
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временных параметрах, пространственных масштабах и логической организации. 
Одну крайность составляют мультипроцессорные системы с общей оперативной 
памятью и с числом процессоров от двух до тысячи. В этой модели каждый цент¬ 
ральный процессор обладает равным доступом ко всей физической памяти и мо¬ 
жет читать и писать отдельные слова с помощью команд ШАЛ и 5Т0КЕ. Время досту¬ 
па к памяти обычно составляет от 10 до 50 нс. Хотя такая система, показанная на 
рис. 8.1, а, может показаться простой, ее реализация представляет собой далеко не 
простую задачу и обычно включает, как мы скоро увидим, большое количество 
скрытно передаваемых сообщений. 


Центральный 
^ процессор 

[смспст 


шн 


Общая 


ни 


[С И память^ 


ш\к І Ш 


Локальная 
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Рис. 8.1. Мультипроцессорная система с общей памятью (а); мультипроцессорная система 
с передачей сообщений (б); глобальная распределенная система (а) 


Следом идут системы (рис. 8.1, б), в которых пары, состоящие из Центрального 
процессора и памяти, соединены высокоскоростной соединительной схемой. Такая 
разновидность системы называется мультипроцессорной системой с передачей со¬ 
общений. Каждый блок памяти является локальным для одного центрального 
процессора, и доступ к ней может получить только этот центральный процессор. 
Процессоры общаются, обмениваясь сообщениями по соединительной схеме. 
При хорошем соединении для передачи сообщения может потребоваться от 10 до 
50 мкс, что все же значительно больше, чем время доступа к памяти в схеме на 
рис. 8.1, а. В этой схеме нет общей глобальной памяти. Мультикомпьютеры (то 
есть системы с передачей сообщений) гораздо легче создать, чем мультипроцессо¬ 
ры (системы с общей памятью), но писать программы для них значительно труд¬ 
нее. Поэтому у каждого жанра есть свои поклонники. 

Третья модель, показанная на рис. 8.1, в, представляет большое количество 
полноценных компьютеров, соединенных глобальной сетью, такой как Интернет, 
и образующих вместе распределенную систему. У каждого компьютера есть своя 
собственная память. Компьютеры в распределенной системе общаются, обменива¬ 
ясь друг с другом сообщениями. Основное различие схем на рис. 8.1, б и рис. 8.1, в 
заключается в том, что во втором случае используются полноценные компьюте¬ 
ры, а время передачи сообщений составляет от 10 до 50 мс, то есть примерно еще 
в 1000 раз больше. Из-за большей величины задержки применение этих слабос¬ 
вязанных систем отличается от использования сильносвязанных систем, показан¬ 
ных на рис. 8.1, б. Величина задержки у всех трех типов систем отличается друг от 
друга на три десятичных порядка. Это отличие примерно соответствует разнице 
между одним днем и тремя годами. 
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Данная глава состоит из трех основных разделов, соответствующих трем моде¬ 
лям на рис. 8.1. Каждый из этих разделов будет начинаться с краткого вступления, 
посвященного соответствующему аппаратному обеспечению. Затем будет описы¬ 
ваться программное обеспечение, в основном вопросы операционной системы для 
данного типа систем. Как мы увидим, у каждой системы есть свой круг вопросов. 


Мультипроцессоры 

Мультипроцессор с общей памятью (или просто мультипроцессор) представля¬ 
ет собой компьютерную систему, в которой два или более центральных процессо¬ 
ра делят полный доступ к общей оперативной памяти. Программа, работающая на 
любом центральном процессоре, видит нормальное (обычно разбитое на страни¬ 
цы) виртуальное адресное пространство. Единственное необычное свойство такой 
системы заключается в том, что центральный процессор может записать какое- 
либо значение в память, а затем, считав это слово снова, получить другое значение 
(потому что другой центральный процессор изменил его). При правильной органи¬ 
зации это свойство формирует основу межпроцессорного обмена информацией: 
один центральный процессор пишет данные в память, а другой считывает их оттуда. 

По большей части мультипроцессорные операционные системы представляют 
собой просто обычные операционные системы. Они обрабатывают системные вы¬ 
зовы, управляют памятью, предоставляют службы файловой системы и управляют 
устройствами ввода-вывода. Тем не менее есть области, в которых они обладают 
уникальными свойствами. К этим областям относятся синхронизация процессов, 
управление ресурсами и планирование. Ниже сначала будет кратко рассмотрено 
мультипроцессорное аппаратное обеспечение, а затем мы перейдем к одному из 
этих вопросов операционной системы. 

Мультипроцессорное аппаратное обеспечение 

У всех мультипроцессоров каждый центральный процессор может адресоваться ко 
всей памяти. Однако по характеру доступа к памяти эти машины делятся на два клас¬ 
са. Мультипроцессоры, у которых каждое слово данных может быть считано с одина¬ 
ковой скоростью, называются ІіМА-мульгипроцессорами (ІМІогт Метогу Ассезз — 
однородный доступ к памяти). В противоположность им мультипроцессоры >ШМА 
(МопІІпНогт Метогу Ассезз — неоднородный доступ к памяти) этим свойством 
не обладают. Почему существует такое различие, станет ясно позднее. Сначала 
будут описаны мультипроцессоры ІІМА, а затем — мультипроцессоры КИМА. 

Архитектура симметричных мультипроцессоров ІІМА 
с общей шиной 

В основе простейшей архитектуры мультипроцессоров лежит идея общей шины 
(рис. 8.2, а). Несколько центральных процессоров и несколько модулей памяти 
одновременно используют одну и ту же шину для общения друг с другом. Когда 
центральный процессор хочет прочитать слово в памяти, он сначала проверяет, 
свободна ли шина. Если шина свободна, центральный процессор выставляет на нее 
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адрес нужного ему слова, подает несколько управляющих сигналов и ждет, пока 
память не выставит нужное слово на шину данных. 

Если шина занята, центральный процессор просто ждет, пока она не освободит¬ 
ся. В этом заключается проблема данной архитектуры. При двух или трех цент¬ 
ральных процессорах состязанием за шину можно управлять. При 32 или 64 цент¬ 
ральных процессорах шина будет постоянно занята, а производительность системы 
будет полностью ограничена пропускной способностью шины. При этом большую 
часть времени центральные процессоры будут простаивать. 


Общая память 




б 


Локальная память 



ѳ 

Рис. 8.2. Три варианта архитектуры мультипроцессоров с общей шиной: без кэша (а); 
с кэшем (б); с кэшем и собственной памятью (в) 
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Решение этой проблемы состоит в том, чтобы добавить каждому центральному 
процессору кэш, как показано на рис. 8.2, б. Кэш может располагаться внутри мик¬ 
росхемы центрального процессора или рядом с центральным процессором, на про¬ 
цессорной плате. Поскольку большое количество обращений к памяти теперь мо¬ 
жет быть удовлетворено прямо из кэша, обращений к шине будет существенно 
меньше, и система сможет поддерживать большее число центральных процессо¬ 
ров. Как правило, кэширование выполняется не для отдельных слов, а для блоков 
по 32 или по 64 байта. При обращении к слову весь блок считывается в кэш цент¬ 
рального процессора, обратившегося к слову. 

Для каждого блока кэша устанавливается режим доступа: либо для него разре¬ 
шается только чтение (в этом случае этот блок может одновременно присутство¬ 
вать в нескольких кэшах), либо разрешается и чтение, и запись (в этом случае этот 
блок не может одновременно присутствовать в нескольких кэшах). При попытке 
записи центральным процессором слова, находящегося в одном или нескольких 
удаленных кэшах, аппаратура шины выставляет на шину специальный сигнал, 
информирующий остальные кэши о записи. Если в остальных кэшах соответству¬ 
ющие блоки «чистые», то есть немодифицированные точные копии блока, нахо¬ 
дящегося в памяти, тогда они могут просто отбросить свои копии и позволить пи¬ 
шущему процессору получить этот блок из памяти. Если же в каком-либо кэше 
содержится «грязная» (то есть модифицированная) копия, она должна быть либо 
записана в память, прежде чем операция записи может быть продолжена, либо пе¬ 
редана напрямую пишущему процессору по шине. Существует много протоколов 
обмена данных между кэшами и памятью. 

Еще один вариант архитектуры мультипроцессоров представлен на рис. 8.2, в, 
В этом случае у каждого центрального процессора имеется не только кэш, но также 
и локальная собственная память, с которой он соединен по выделенной (индивиду¬ 
альной) шине. Для оптимального использования подобной конфигурации компи¬ 
лятор должен поместить текст программы, константы, стеки (то есть все неизме¬ 
няемые данные), а также локальные переменные в локальные модули памяти. При 
этом общая память используется только для общих модифицируемых переменных. 
В большинстве случаев такая схема использования памяти сильно снижает тра¬ 
фик по шине, но для ее реализации требуются специальные действия со стороны 
компилятора. 

Мультипроцессоры 11МА, использующие 
координатные коммутаторы 

Даже при оптимальном использовании кэша наличие всего одной общей шины 
ограничивает число ЕПМА-мультипроцессоров тридцатью двумя или шестьюде¬ 
сятью четырьмя. Чтобы преодолеть это ограничение, требуется другая схема 
соединительной сети. Довольно простая схема соединения п центральных про¬ 
цессоров и к модулей памяти представляет собой координатный коммутатор 
(рис. 8.3). Координатные коммутаторы десятилетиями использовались в телефон¬ 
ной сети для соединения группы входных и группы выходных линий произволь¬ 
ным способом. 
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Рис. 8.3. Координатный коммутатор 8 х 8 (а); разомкнутый переключатель (б); 
замкнутый переключатель (в) 

На каждом пересечении горизонтальной (входной) и вертикальной (выходной) 
линий располагается координатный переключатель. Он представляет собой не¬ 
большой переключатель, который может быть открыт или закрыт, в зависимости 
от того, должны быть соединены вертикальная и горизонтальная линии или нет. 
На рис. 8.3, а изображены три одновременно замкнутых переключателя, что по¬ 
зволяет одновременно соединить пары (центральный процессор, блок памяти) 
(001, 000), (101, 101) и (НО, 010). Возможны и другие разнообразные комбина¬ 
ции. Число комбинаций в данном примере равно числу вариантов расположения 
на шахматной доске восьми ладей таким образом, чтобы они не находились под 
ударом друг друга. 

Одно из самых замечательных свойств координатного коммутатора заключа¬ 
ется в том, что он представляет собой неблокирующую сеть. Это означает, что ни 
один центральный процессор не получает отказа соединения по причине занятости 
какого-либо переключателя (при условии, что сам требующийся модуль памяти сво¬ 
боден). Более того, при такой схеме не требуется планирования доступа к памяти. 
Даже если семь любых соединений уже установлены, всегда можно соединить ос¬ 
тавшийся центральный процессор с оставшимся модулем памяти. 

Основной недостаток координатного коммутатора состоит в том, что число 
переключателей растет пропорционально квадрату от числа центральных про¬ 
цессоров. При 1000 центральных процессоров и 1000 модулях памяти потребует¬ 
ся миллион переключателей. Такой огромный координатный коммутатор просто 
не реализуем. Тем не менее для систем среднего размера архитектура координат¬ 
ного коммутатора является применимой. 
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Мультипроцессоры ІІМА, использующие 
многоступенчатые коммутаторные сети 

Принципиально другая архитектура мультипроцессоров базируется на простых 
коммутаторах 2x2 (рис. 8.4, а ). У такого коммутатора два входа и два выхода. Со¬ 
общения, поступающие по любой из входных линий, могут переключаться на лю¬ 
бую выходную линию. Сообщения в рассматриваемом нами мультипроцессоре 
будут состоять из четырех частей (рис. 8.4, б). Поле Мосіиіе (модуль) указывает 
модуль памяти. Поле Асісігезз (адрес) указывает адрес внутри модуля. Поле Орсосіе 
(код операции) указывает операцию, то есть КЕАО (чтение) или ШІТЕ (запись). На¬ 
конец, необязательное поле Ѵаіие (значение) может содержать операнд, например 
32-разрядное слово, которое должно быть записано операцией МКІТЕ. По значению 
поля Мосіиіе коммутатор определяет, по какой из двух выходных линий следует 
отправить сообщение. 
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Рис. 8.4. Коммутатор 2x2 (а); формат сообщения (б) 

С помощью данного коммутатора 2x2 можно построить самые различные мно¬ 
гоступенчатые коммутаторные сети [5, 31, 189]. Один из вариантов таких сетей 
представляет собой сеть омега, показанная на рис. 8.5. Это сеть без излишеств, 
так сказать, экономический класс сетей. В данном примере она соединяет восемь 
центральных процессоров с восемью модулями памяти всего 12 коммутаторами. 
В более общем случае для п центральных процессоров и п модулей памяти потребу¬ 
ется 1о§ 2 и ступеней с п /2 коммутаторами в каждой ступени. Таким образом, в це¬ 
лом для сети омега потребуется (п/ 2)1о§ 2 и коммутаторов, что значительно мень¬ 
ше, чем п 2 коммутаторов, особенно для больших п. 


Центральные 3 ступени Модули 

процессоры ,-*-, памяти 



Рис. 8.5. Коммутирующая сеть омега 
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Схему соединений в сети омега часто называют идеальным тасованием, по¬ 
скольку на каждой ступени перемешивание сигналов напоминает тасование коло¬ 
ды карт. Чтобы понять принципы работы сети омега, предположим, что централь¬ 
ному процессору 011 нужно прочитать слово из модуля памяти 110. Центральный 
процессор посылает коммутатору Ш сообщение КЕАв, содержащее НО в поле 
Мойиіе. Старший (то есть самый левый) бит этого поля коммутатор использует 
для выбора маршрута, 0 означает выбор верхнего выхода, а 1 — нижнего. Посколь¬ 
ку бит равен 1, сообщение направляется по нижнему выходу коммутатору 2Э. 

Все коммутаторы второй ступени, включая коммутатор 2Э, используют для 
маршрутизации второй бит. Он также равен 1, поэтому сообщение передается по 
нижнему выходу коммутатору ЗБ. Он проверяет младший бит, и поскольку бит 
равен 0, то сообщение передается по верхнему выходу и попадает, как и требова¬ 
лось, к модулю памяти 110. Путь этого сообщения помечен символом а. 

По мере продвижения по коммутирующей сети левые биты номера модуля ока¬ 
зываются более не нужными. Они моіут использоваться для запоминания вход¬ 
ных линий, чтобы ответ мог найти обратный путь. Для пути а входные линии име¬ 
ют номера 0 (верхний вход Ш), 1 (нижний вход 2Б) и 1 (нижний вход ЗБ). Ответ 
направляется по адресу 011, обработка которого производится справа налево. 

В то же самое время центральный процессор 001 хочет записать слово в модуль 
памяти 001. Этот процесс происходит аналогично описанному выше. Сообщение 
направляется по верхнему, верхнему и нижнему выходу (путь отмечен символом б). 
Когда сообщение доходит до модуля памяти, поле Мойиіе содержит 001, то есть 
путь, пройденный сообщением. Поскольку эти два запроса не используют общих 
коммутаторов, линий и модулей памяти, они могут выполняться параллельно. 

Теперь посмотрим, что произойдет, если центральный процессор 000 одновре¬ 
менно с этим захочет обратиться к модулю памяти 000. Его запрос войдет в конф¬ 
ликт с запросом центрального процессора 001 на коммутаторе ЗА. Одному из них 
придется подождать. В отличие от координатного коммутатора, сеть омега представ¬ 
ляет собой блокирующую сеть. Не все наборы запросов могут быть обработаны од¬ 
новременно. Возникают конфликты из-за использования линии или коммутатора 
как между запросами к памяти, так и между ответами памяти на эти запросы. 

Было бы желательно распределить запросы к памяти более равномерно между 
модулями. Один из распространенных методов заключается в использовании 
младших разрядов в качестве номеров модулей. Представьте, например, байт-ори- 
ентированное адресное пространство компьютера, обращающегося к памяти, в ос¬ 
новном с 32-разрядными словами. Два младших разряда при этом обычно будут 
равны 00, но следующие три бита будут распределены равномерно. Если использо¬ 
вать эти три бита в качестве номера модуля, последовательно адресуемые слова ока¬ 
жутся в последовательных модулях. Система памяти, в которой соседние слова 
хранятся в различных модулях памяти, называется чередующейся. Чередующая¬ 
ся память позволяет добиться максимального распараллеливания, так как большин¬ 
ство обращений к памяти представляют собой запросы по идущим подряд адресам. 
Возможно создание неблокирующих коммутирующих сетей, предоставляющих 
каждому центральному процессору несколько путей к каждому модулю памяти 
для лучшего распределения трафика. 
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Мультипроцессоры ЫІІМА 

Для мультипроцессоров ІША с единственной общей шиной пределом является 
несколько десятков центральных процессоров, в то время как мультипроцессорам 
с координатным коммутатором или коммутирующей сетью требуется большое 
количество (дорогого) аппаратного обеспечения, и количество центральных про¬ 
цессоров в них не намного больше. Чтобы создать мультипроцессор с числом цен¬ 
тральных процессоров, превосходящем 100, нужно чем-то пожертвовать. Обычно 
в жертву приносится идея одинакового времени доступа ко всем модулям памяти. 
Таким образом, мы получаем концепцию мультипроцессоров 1Ѵ11МА (Ыопііпііогт 
Метогу Ассезз — неоднородный доступ к памяти), о которых упоминалось выше. 
Как и их родственники ІЛМА, мультипроцессоры КІЛѴ1А предоставляют единое 
адресное пространство для всех центральных процессоров, но в отличие от ІЛМА- 
машин доступ к локальной памяти в них быстрее, чем к удаленным модулям. Таким 
образом, все программы, написанные для ИМ А, будут работать и на мультипро¬ 
цессорах ЫІІМА, но их производительность будет ниже, чем на машинах ІЛМА при 
той же тактовой частоте процессоров. 

У машин N11 МА есть три ключевые характеристики, которые, взятые вместе, 
отличают их от других мультипроцессоров. 

1. Для всех центральных процессоров имеется единое адресное пространство. 

2. Доступ к удаленным модулям памяти осуществляется при помощи специ¬ 
альных команд процессора ШАО и 5Т0КЕ. 

3. Доступ к удаленным модулям памяти медленнее, чем к локальной памяти. 

В том случае, если доступ к удаленной памяти не является скрытым (то есть 

кэширование не применяется), система называется ІЧС-ІЧІІМА^о СасЫп§М1ША — 
система ЫІІМА без кэширования). При наличии когерентных кэш-модулей сис¬ 
тема называется СС^ІЛѴІА (СасЬе-СоЬегепІ ЫІШ А — система ЫГГМ А с когерент¬ 
ным кэшированием). 

Наиболее популярным подходом при построении больших мультипроцессоров 
СС-МІЛМА в настоящий момент является каталоговый мультипроцессор. Его 
идея состоит в поддержании базы данных, в которой содержится информация 
о том, где располагается каждая строка кэша и ее состояние. При обращении к стро¬ 
ке кэша база данных получает запрос на поиск этой строки и выдает ее состояние 
(«чистая» или «грязная»). Поскольку запросы этой базе данных направляются на 
каждой команде процессора, обращающейся к памяти, эта база должна храниться 
в крайне быстром специальном аппаратном устройстве, способном выдавать ответ 
за долю цикла шины. 

Чтобы сделать идею каталоговых мультипроцессоров более понятной, рассмот¬ 
рим простой (гипотетический) пример системы, состоящей из 256 узлов, каждый 
из которых содержит один центральный процессор и 16 Мбайт оперативной па¬ 
мяти, соединенной с центральным процессором локальной шиной. Общий объем 
ОЗУ составляет 2 32 байт (4 Гбайт), разделенных на 2 26 линий кэша по 64 байт каж¬ 
дый. Эта память статически распределяется между узлами, с адресами от 0 до 16 М 
в узле 0, от 16 до 32 М в узле 1 и т. д. Узлы соединяются сетью (рис. 8.6, а). В каж¬ 
дом узле также располагаются записи каталога для 2 18 64-байтовых линий кэша, 
составляющих 2 24 байт памяти. Пока что мы будем предполагать, что каждая строка 
может содержаться максимум в одном кэше. 
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Рис. 8.6. Каталоговый мультипроцессор о 256 узлами (а); разделение 
32-разрядного адреса на поля (б); каталог в узле 36 (в) 

Чтобы понять, как работает каталог, рассмотрим выполнение команды ШАЛ цен¬ 
трального процессора 20 с обращением к строке кэша. Сначала центральный про¬ 
цессор, издающий команду ШАЛ, передает ее аргумент своему диспетчеру памяти, 
который преобразует его в физический адрес, например 0x24000108. Диспетчер 
памяти расщепляет этот адрес на три части, показанные на рис. 8.6, б. В десятичном 
виде эти части выглядят как узел 36, строка 4 и смещение 8. Диспетчер памяти 
видит, что центральный процессор обращается к слову памяти в узле 36, а не в узле 20, 
поэтому он посылает узлу 36 по соединительной сети сообщение с запросом, на¬ 
ходится ли эта строка в кэше, и если да, то где. 

Когда запрос приходит по соединительной сети на узел 36, он направляется к 
аппаратуре каталога. Это аппаратное обеспечение обращается по индексу в свою 
таблицу, состоящую из 2 18 записей, по одной для каждой строки кэша, и достает из 
нее запись 4. Как видно на рис. 8.6, в, эта строка не является кэшированной, по¬ 
этому аппаратное обеспечение достает ее из локальной памяти, отправляет узлу 20 
и отмечает в таблице, что теперь эта строка кэширована в узле 20. 

Теперь рассмотрим пример другого запроса. На этот раз у узла 36 запрашива¬ 
ется строка 2. Как показано на рис. 8.6, ѳ, эта строка кэширована в узле 82. При этом 
аппаратное обеспечение изменяет запись, отмечая, что теперь эта строка находит¬ 
ся в узле 20, и посылает узлу 82 команду переслать эту строку узлу 20, а также по¬ 
метить свою строку кэша как недействительную. Обратите внимание, что даже так 
называемый «мультипроцессор с общей памятью» вынужден пересылать большое 
количество сообщений незаметно для верхнего уровня. 
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Посчитаем, сколько памяти занимают каталоги, У каждого узла есть 16 Мбайт 
оперативной памяти и 2 18 9-битовых записей для учета этой памяти. Таким обра¬ 
зом, накладные расходы на содержание каталога составляют около 9x2 18 бит, что 
составляет около 1,76 % от 16 Мбайт. Эта величина не так уж велика и должна быть 
приемлемой (хотя для каталога должна использоваться высокоскоростная память, 
что увеличивает ее стоимость). Даже при 32-байтовых строках кэша накладные 
расходы на содержание каталога будут около 4 %. При 128-байтовых строках кэша 
накладные расходы не будут превышать 1 %. 

Очевидное ограничение такой схемы заключается в том, что строка может быть 
кэширована только в одном узле. Чтобы позволить кэшировать строку одновре¬ 
менно в нескольких узлах, нам потребуется какой-то способ обнаружения всех 
этих строк чтобы, например, пометить их все как недействительные или чтобы 
обновить их при записи. Возможны различные варианты реализации этого, но об¬ 
суждение всех этих вариантов выходит за пределы данной книги. 

Типы мультипроцессорных операционных систем 

Перейдем теперь от обсуждения аппаратного обеспечения мультипроцессоров к 
рассмотрению программного обеспечения, в частности к обсуждению мультипро¬ 
цессорных операционных систем. Возможны различные варианты организации 
данных систем. Ниже будут рассмотрены три из них. 

Каждому центральному процессору — свою 
операционную систему 

Простейший способ организации мультипроцессорных операционных систем 
состоит в том, чтобы статически разделить оперативную память по числу цент¬ 
ральных процессоров и дать каждому центральному процессору свою собственную 
память с собственной копией операционной системы. В результате п центральных 
процессоров будут работать как п независимых компьютеров. В качестве оче¬ 
видного варианта оптимизации можно позволить всем центральным процессо¬ 
рам совместно использовать код операционной системы и хранить только ин¬ 
дивидуальные копии данных (рис. 8.7). Квадратики, помеченные словом Эаіа, 
означают приватные данные операционной системы для каждого центрального 
процессора. 


Центральный Центральный Центральный Центральный Устройство 

процессор 1 процессор 2 процессор 3 процессор 4 Память ввода-вывода 



Рис. 8.7. Разделение памяти мультипроцессора между четырьмя центральными 
процессорами с общей копией кода операционной системы 
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Тем не менее такая схема лучше, чем п независимых компьютеров, так как она 
позволяет всем машинам совместно использовать набор дисков и других устройств 
ввода-вывода, а также обеспечивает гибкое совместное использование памяти. 
Например, если требуется запустить большую программу, одному из центральных 
процессоров может быть выделена большая порция памяти на время выполнения 
этой программы. Кроме того, процессы могут эффективно общаться друг с дру¬ 
гом, если одному процессу будет позволено писать данные в память, а другой про¬ 
цесс будет их считывать в этом месте. Но с точки зрения операционной системы 
наличие операционной системы у каждого центрального процессора является 
крайне примитивным подходом. 

Следует отметить четыре аспекта данной схемы, возможно, не являющихся оче¬ 
видными. Во-первых, когда процесс обращается к системному вызову, системный 
вызов перехватывается и обрабатывается его собственным центральным процес¬ 
сором при помощи структур данных в таблицах операционной системы. 

Во-вторых, поскольку у каждой операционной системы есть свои собственные 
таблицы, у нее есть также и свой набор процессов, которые она сама планирует. 
Совместного использования процессов нет. Если пользователь регистрируется на 
центральном процессоре 1, то все его процессы работают на центральном процес¬ 
соре 1. В результате может случиться так, что центральный процессор 1 окажется 
загружен работой, тогда как центральный процессор 2 будет простаивать. 

В-третьих, совместного использования страниц также нет. Может случиться 
так, что у центрального процессора 2 много свободных страниц, в то время как цен¬ 
тральный процессор 1 будет постоянно заниматься свопингом. И нет никакого 
способа занять свободные страницы у соседнего процессора, так как выделение 
памяти статически фиксировано. 

В-четвертых, и это хуже всего, если операционная система поддерживает 
буферный кэш недавно использованных дисковых блоков, то каждая операцион¬ 
ная система будет выполнять это независимо от остальных. Таким образом, может 
случиться так, что некоторый блок диска будет присутствовать в нескольких бу¬ 
ферах одновременно, причем в нескольких буферах сразу он может оказаться мо¬ 
дифицированным, что приведет к порче данных на диске. Единственный способ 
избежать этого заключается в полном отказе от блочного кэша, что значительно 
снизит производительность системы. 

Мультипроцессоры типа «хозяин-подчиненный» 

По причине приведенных выше соображений такая модель теперь используется 
редко, хотя она применялась на заре эпохи мультипроцессоров, когда ставилась 
цель просто перенести существующие операционные системы на какой-либо но¬ 
вый мультипроцессор как можно быстрее. Вторая модель показана на рис 8.8. 
Здесь используется всего одна копия операционной системы, находящаяся на цен¬ 
тральном процессоре 1 и отсутствующая на других центральных процессорах. Все 
системные вызовы перенаправляются для обработки на центральный процессор 1. 
Центральный процессор 1 может также выполнять процессы пользователя, если 
у него будет оставаться для этого время. Такая схема называется «хозяин-подчи- 
ненный», так как центральный процессор 1 является «хозяином», то есть ведущим, 
а все остальные процессоры — подчиненными, или ведомыми. 
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Рис. 8.8. Модель мультипроцессора «хозяин-подчиненный» 

Модель мультипроцессора «хозяин-подчиненный» позволяет решить большин¬ 
ство проблем первой модели. В этой модели используется единая структура дан¬ 
ных (например, один общий список или набор приоритетных списков), учитыва¬ 
ющая готовые процессы. Когда центральный процессор переходит в состояние 
простоя, он запрашивает у операционной системы процесс, который можно обра¬ 
батывать, и при наличии готовых процессов операционная система назначает это¬ 
му процессору процесс. Поэтому при такой организации никогда не может слу¬ 
читься так, что один центральный процессор будет простаивать, в то время как 
другой центральный процессор перегружен. Страницы памяти могут динамичес¬ 
ки предоставляться всем процессам. Кроме того, в такой системе есть всего один 
общий буферный кэш блочных устройств, поэтому дискам не грозит порча дан¬ 
ных, как в предыдущей модели при попытке использования блочного кэша. 

Недостаток этой модели состоит в том, что при большом количестве централь¬ 
ных процессоров хозяин может стать узким местом системы. Ведь ему приходится 
обрабатывать все системные вызовы от всех центральных процессоров. Например, 
если обработка системных вызовов занимает 10 % времени, тогда 10 центральных 
процессоров завалят хозяина работой, а при 20 центральных процессорах хозяин 
уже не будет успевать их обрабатывать, и система начнет простаивать. Следова¬ 
тельно, такая модель проста и работоспособна для небольших мультипроцессоров, 
но на больших она работать не может. 

Симметричные мультипроцессоры 

Третья модель, представляющая собой симметричные мультипроцессоры (5МР, 
ЗуттеГгіс МиІІіРгосеззог), позволяет устранить перекос предыдущей модели. Как 
и в предыдущей схеме, в памяти находится всего одна копия операционной сис¬ 
темы, но выполнять ее может любой процессор. При системном вызове на цент¬ 
ральном процессоре, обратившемся к системе с системным вызовом, происходит 
прерывание с переходом в режим ядра и обработкой системного вызова. Модель 
симметричного мультипроцессора показана на рис. 8.9. 

Эта модель обеспечивает динамический баланс процессов и памяти, поскольку 
в ней имеется всего один набор таблиц операционной системы. Она также позво¬ 
ляет избежать простоя системы, связанного с перегрузкой ведущего центрального 
процессора («хозяина»), так как в ней нет ведущего центрального процессора. 
И все же данная модель имеет собственные проблемы. В частности, если код опе¬ 
рационной системы будет выполняться одновременно на двух или более централь- 



570 


Глава 8. Многопроцессорные системы 


ных процессорах, произойдет катастрофа. Представьте себе два центральных про¬ 
цессора, одновременно берущих один и тот же процесс для запуска или запраши¬ 
вающих одну и ту же свободную страницу памяти. Простейший способ разреше¬ 
ния подобных проблем заключается в связывании мьютекса (то есть блокировки) 
с операционной системой, в результате чего вся система превращается в одну боль¬ 
шую критическую область. Когда центральный процессор хочет выполнять код 
операционной системы, он должен сначала получить мьютекс. Если мьютекс за¬ 
блокирован, процессор вынужден ждать. Таким образом, любой центральный про¬ 
цессор может выполнить код операционной системы, но в каждый момент време¬ 
ни только один из них будет делать это. 


Центральный Центральный Центральный Центральный Устройство 

процессор 1 процессор 2 процессор 3 процессор 4 Память ввода-вывода 



Рис. 8.9. Модель симметричного мультипроцессора 

Такая модель работает, но она практически так же плоха, как и модель «хозя¬ 
ин-подчиненный». Опять же предположим, что 10 % всего процессорного време¬ 
ни расходуется на выполнение самой операционной системы. При 20 центральных 
процессорах большинство процессоров будут подолгу стоять в длинных очередях, 
ожидая разрешения доступа к мьютексу. К счастью, такую ситуацию легко испра¬ 
вить. Многие части операционной системы независимы друг от друга. Например, 
один центральный процессор может заниматься планированием, в то время как 
другой центральный процессор будет выполнять обращение к файловой системе, 
а третий обрабатывать страничное прерывание. 

Такое наблюдение приводит к расщеплению операционной системы на неза¬ 
висимые критические области, не взаимодействующие друг с другом. У каждой 
критической области есть свой мьютекс, поэтому только один центральный процес¬ 
сор может выполнять ее в каждый момент времени. Таким образом можно достичь 
большей степени распараллеливания. Однако может случиться, что некоторые таб¬ 
лицы, например таблица процессов, используются в нескольких критических облас¬ 
тях. Так, таблица процессов требуется для планирования, но также для выполнения 
системного вызова Гогк и для обработки сигналов. Для каждой таблицы, исполь¬ 
зующейся несколькими критическими областями, требуется свой собственный 
мьютекс. Итак, в каждый момент времени каждая критическая область может вы¬ 
полняться только одним центральным процессором, а также к каждой критической 
таблице может быть предоставлен доступ только одному центральному процессору. 

Подобная организация используется в большинстве современных мультипро¬ 
цессоров. Сложность написания операционной системы для такой машины за- 





Мультипроцессоры 


571 


ключается не в том, что программный код сильно отличается от обычной операци¬ 
онной системы. Нет. Самым сложным является расщепление операционной сис¬ 
темы на критические области, которые могут выполняться параллельно на разных 
центральных процессорах, не мешая друг другу даже косвенно. Кроме того, каж¬ 
дая таблица, используемая двумя и более критическими областями, должна быть 
отдельно защищена мьютексом, а все программы, пользующиеся этой таблицей, 
должны корректно использовать мьютекс. 

Кроме того, следует уделить особое внимание вопросу избежания взаимобло¬ 
кировок. Если двум критическим областям одновременно потребуются таблица Л 
и таблица В и они затребуют эти таблицы в разном порядке, то рано или поздно 
возникнет взаимоблокировка, причину появления которой будет очень трудно 
определить. Теоретически всем таблицам можно поставить в соответствие целые 
числа и потребовать от всех критических областей запрашивать эти таблицы по 
порядку номеров. Такая стратегия позволяет избежать взаимоблокировок, но она 
требует от программиста детального исследования того, какие таблицы потребу¬ 
ются каждой критической области, чтобы запросить их в правильном порядке. 

При изменении программы со временем критической области может потребо¬ 
ваться новая таблица, которая не была нужна ранее. Если изменением программы 
занимается новый программист, не понимающий всей логики системы, он может 
поддаться искушению просто захватить мьютекс в тот момент, когда требуется 
таблица, и отпустить его, когда таблица более не нужна. Однако именно такие про¬ 
стые и кажущиеся разумными действия могут привести к взаимоблокировке, что 
с точки зрения пользователя выглядит как зависание системы. Очень не просто 
грамотно спроектировать систему, но поддерживать ее в правильном состоянии в 
течение нескольких лет и при этом совершенствовать систему меняющимся шта¬ 
том программистов крайне трудно. 

Синхронизация в мультипроцессорах 

В мультипроцессорных системах часто требуется синхронизация центральных 
процессоров. Мы только что рассмотрели случай, в котором критические области 
и таблицы нуждались в защите при помощи мьютексов. Рассмотрим теперь более 
детально, как эта синхронизация работает в мультипроцессоре. Как мы вскоре уви¬ 
дим, это далеко не тривиально. 

Для начала нам потребуются соответствующие примитивы синхронизации. 
Если процесс на однопроцессорной системе обращается к системному вызову, ко¬ 
торый требует доступа к некой критической таблице, программа ядра может про¬ 
сто запретить прерывания, прежде чем обратиться к таблице. Однако на мульти¬ 
процессоре запрет прерывания повлияет только на один центральный процессор, 
выполнивший команду запрета прерываний. Остальные центральные процессоры 
продолжат свою работу и смогут получить доступ к критической таблице. Требу¬ 
ется специальный мьютекс-протокол, который будет выполняться всеми централь¬ 
ными процессорами, чтобы гарантировать работу взаимного исключения. 

Сердцем любого практического мьютекс-протокола является команда процессо¬ 
ра, позволяющая исследовать и изменить слово в памяти за одну операцию. Пример 
использования команды Т5І. (Тезе аші 8еі Ьоск — проверить и установить блоки- 
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ровку) для реализации критических областей был рассмотрен в листинге 2.2. Как 
уже было сказано, эта команда считывает слово памяти в регистр процессора. 
Одновременно она записывает 1 (или другое ненулевое значение) в слово памяти. 
Конечно, для выполнения операций чтения и записи памяти требуется два цикла 
шины. На однопроцессорной машине, поскольку одна команда процессора не мо¬ 
жет быть прервана на полпути, команда ТЗЬ работает должным образом. 

Теперь представьте себе, что может произойти на мультипроцессоре. На рис. 8.10 
показан наихудший случай совпадения по времени обращений к слову памяти 
по адресу 1000, начальное состояние которого 0. На шаге 1 центральный процес¬ 
сор 1 считывает слово и получает 0. На шаге 2, прежде чем центральный процес¬ 
сор 1 успевает изменить это слово, центральный процессор 2 также считывает сло¬ 
во и тоже получает 0. На шаге 3 центральный процессор 1 записывает в это слово 1. 
На шаге 4 центральный процессор 2 также записывает в это слово 1. Оба цент¬ 
ральных процессора получили от команды Т$І- 0, поэтому оба считают себя вправе 
получить доступ к критической области. Таким образом, взаимное исключение не 
срабатывает. 


Центральный Центральный 

процессор 1 Слово 1000 Память процессор 2 



записывает 1 записывает 1 

Рис. 8.10. Команда Т$І_ может работать неверно, если не заблокировать шину 

Для разрешения этой проблемы команда Т$1- сначала должна блокировать шину, 
не допуская обращения к ней других центральных процессоров, затем выполнить 
оба обращения к памяти, после чего разблокировать шину. Как правило, для блоки¬ 
ровки шины сначала выполняется обычный запрос шины по стандартному прото¬ 
колу, затем устанавливается в 1 некая специальная линия шины. Пока эта линия 
шины установлена в 1, никакой другой центральный процессор не может получить 
к ней доступ. Такая команда может быть выполнена только на шине, у которой есть 
необходимые специальные линии и (аппаратный) протокол для их использования. 
Современные шины обладают подобными свойствами, но на старых шинах это 
было невозможно, и команда Т5І. не могла быть выполнена корректно. Поэтому для 
чисто программной синхронизации был разработан протокол Петерсона [263]. 

Если команда Т5І. корректно реализована и применяется, она гарантирует пра¬ 
вильную работу взаимного исключения. Однако подобный способ реализации 
взаимного исключения использует спин-блокировку, так как запрашивающий 
центральный процессор находится в цикле опроса блокировки с максимальной 
скоростью. Этот метод является не только тратой времени запрашивающего цент¬ 
рального процессора (или процессоров), но он также может накладывать значи- 
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тельную нагрузку на шину или память, существенно снижая скорость работы 
всех остальных центральных процессоров, пытающихся выполнять свою обычную 
работу. 

На первый взгляд может показаться, что наличие кэширования должно устра¬ 
нить проблему конкуренции за шину, но это не так. Теоретически, как только за¬ 
прашивающий центральный процессор прочитал слово блокировки, он должен по¬ 
лучить его копию в свой кэш. Пока ни один другой центральный процессор не 
предпринимает попыток использовать это слово, запрашивающий центральный 
процессор может работать с ним в своем кэше. Когда центральный процессор, 
владеющий словом блокировки, записывает в него 1, протокол кэша автомати¬ 
чески помечает как недействительные все копии этого слова в удаленных кэшах, 
требуя получения правильных значений. 

Проблема заключается в том, что кэш оперирует блоками по 32 или 64 байт. 
Обычно слова, окружающие слово блокировки, нужны центральному процессору, 
удерживающему это слово. Поскольку команда Т5І_ представляет собой запись (так 
как она модифицирует слово блокировки), ей требуется монопольный доступ к 
блоку кэша, содержащему слово блокировки. Таким образом, каждая команда Т5І_ 
помечает блок кэша владельца блокировки как недействительный и получает при¬ 
ватную, эксклюзивную копию для запрашивающего центрального процессора. Как 
только владелец блокировки изменит слово, соседнее с блокировкой, блок кэша 
перемещается на его машину. В результате весь блок кэша, содержащий слово 
блокировки, постоянно как челнок мотается взад-вперед от центрального про¬ 
цессора, удерживающего блокировку, к центральному процессору, пытающемуся 
ее получить. Все это создает довольно значительный и совершенно излишний 
трафик шины. 

Проблему можно было бы решить, если бы удалось избавиться от всех опера¬ 
ций записи, вызванных командой Т51. запрашивающей стороны. Это можно сделать, 
если запрашивающая сторона сначала будет выполнять простую операцию чтения, 
чтобы убедиться, что мьютекс свободен. Только убедившись, что он свободен, цен¬ 
тральный процессор выполняет команду Т5Ц чтобы захватить его. В результате 
большинство операций опроса представляют собой операции чтения, а не опера¬ 
ции записи. Когда мьютекс считан, владелец выполняет операцию записи, для чего 
требуется монопольный доступ. При этом все остальные копии этого блока кэша 
объявляются недействительными. При следующей операции чтения запрашива¬ 
ющий центральный процессор перезагрузит этот блок кэша. Обратите внимание, 
что при одновременном споре двух центральных процессоров за один и тот же 
мьютекс может случиться, что они одновременно увидят, что мьютекс свободен, 
и одновременно выполнят команду Т51.. Ничего страшного в этом случае не про¬ 
изойдет, так как выполнена будет только одна команда Т51. и такая ситуация не 
приведет к состоянию состязания. Если вы видите, что мьютекс свободен, и тут же 
пытаетесь его схватить командой Т51_, то нет никакой гарантии успеха данного пред¬ 
приятия. Мьютекс может успеть захватить кто-либо другой. 

Другой способ снижения шинного трафика заключается в использовании ал¬ 
горитма двоичного экспоненциального отката, применяемого в сети ЕіЬегпеІ [11]. 
Вместо постоянного опроса, показанного в листинге 2.2, между опросами может 
быть вставлен цикл задержки. Вначале задержка представляет собой одну команду. 
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Если мьютекс занят, задержка удваивается, учетверяется и т. д. до некоторого мак¬ 
симального уровня. При низком уровне мы получим быструю реакцию при осво¬ 
бождении мьютекса, зато потребуется больше обращений к шине для чтения бло¬ 
ка кэша. Высокий максимальный уровень позволит уменьшить число лишних 
обращений к шине за счет более медленной реакции программы на освобождение 
мьютекса. Использование алгоритма двоичного экспоненциального отката не за¬ 
висит от применения операций чистого чтения перед командой Т5Е 

Еще более удачная идея заключается в том, чтобы каждому центральному про¬ 
цессору, желающему заполучить мьютекс, позволить опрашивать свою собствен¬ 
ную переменную блокировки (рис. 8.11) [233], Во избежание конфликтов перемен¬ 
ная должна располагаться в не используемом для других целей блоке кэша. Работа 
алгоритма состоит в том, что центральный процессор, которому не удается запо¬ 
лучить мьютекс, захватывает переменную блокировки и присоединяется к концу 
списка центральных процессоров, ожидающих освобождения мьютекса. Когда цен¬ 
тральный процессор, удерживающий мьютекс, покидает критическую область, он 
освобождает приватную переменную, проверяемую первым центральным процес¬ 
сором в списке (в его собственном кэше). Тем самым следующий центральный 
процессор получает возможность войти в критическую область. Покинув крити¬ 
ческую область, этот процессор освобождает переменную блокировки, тестируе¬ 
мую следующим процессором и т. д. Хотя такой протокол несколько сложен (это 
необходимо, чтобы не допустить одновременного присоединения двух централь¬ 
ных процессоров к концу списка), он эффективен и не страдает от проблемы голо¬ 
дания. Подробнее см. указанную выше статью. 


Центральный 
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Центральный процессор 2 
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Общая память 


Центральный процессор 1 
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(приватный) мьютекс 

Центральный процессор 4 
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Когда центральный процессор 1 
покидает критическую область, 
он освобождает настоящий 
мьютекс, опрашиваемый в цикле 
центральным процессором 2 


Рис. 8.11. Использование нескольких мьютексов во избежание пробуксовки кэша 


Ожидание в цикле или переключения? 

До сих пор мы предполагали, что центральный процессор, которому требуется 
мьютекс, просто ждет, пока тот не освободится, опрашивая его состояние посто¬ 
янно или периодически, либо присоединяясь к списку ожидающих процессоров. 
В некоторых случая альтернативы простому ожиданию нет. Например, предполо¬ 
жим, что какой-либо центральный процессор простаив ает- и ему нужен доступ к 
общему списку готовых процессов, чтобы выбрать оттуда процесс и запустить его. 
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Если список готовых процессов заблокирован, простаивающему центральному 
процессору будет просто более нечем себя занять. Он должен ждать, пока список 
готовых процессов не освободится. 

Однако в некоторых случаях у процессора может быть выбор. Например, если 
какому-либо потоку на центральном процессоре потребуется доступ к блочному 
кэшу файловой системы, заблокированному в данный момент, центральный про¬ 
цессор может решить не ждать, а переключиться на другой поток. Вопрос приня¬ 
тия решения о том, ждать или переключиться на другой поток, являлся предме¬ 
том многочисленных исследований, некоторые из них будут обсуждаться ниже. 
Обратите внимание, что на однопроцессорной системе такого вопроса не возника¬ 
ет, так как опрос в цикле ни имеет смысла при отсутствии другого центрального 
процессора, способного освободить мьютекс. Если поток пытается получить мью¬ 
текс и ему это не удается, он всегда блокируется, чтобы дать возможность владель¬ 
цу мьютекса работать и освободить мьютекс. 

Если допустить, что оба варианта (опрос в цикле и переключение потоков) вы¬ 
полнимы, возникает следующая ситуация. Циклический опрос напрямую расхо¬ 
дует процессорное время. Периодическая проверка состояния мьютекса не явля¬ 
ется продуктивной работой. Переключение процессов, однако, также расходует 
циклы процессора, так как для этого требуется сохранить текущее состояние пото¬ 
ка, получить мьютекс списка свободных процессов, выбрать из этого списка поток, 
загрузить его состояние и передать ему управление. Более того, кэш центрального 
процессора будет содержать не те блоки, поэтому после переключения потоков 
возможно много промахов кэша. Также вероятны ошибки ТЬВ. Наконец, потре¬ 
буется переключение обратно на исходный поток, результатом которого снова бу¬ 
дут промахи кэша. Циклы процессора, потраченные на эти два переключения кон¬ 
текста плюс промахи кэша, представляют собой существенные накладные расходы. 

Если известно, что мьютексы удерживаются, как правило, в течение 50 мкс, 
а переключение с одного потока на другой занимает 1 мс, а также 1 мс требует об¬ 
ратное переключение, то более эффективное решение состоит в простом ожида¬ 
нии освобождения мьютекса в цикле. С другой стороны, если средний мьютекс 
удерживается на 10 мс, то два переключения контекста являются вполне оправ¬ 
данными. Проблема в том, что длительность нахождения процессов в критичес¬ 
ких областях может варьироваться в широких пределах, поэтому выбор верного 
решения непрост. 

Одно решение заключается в том, чтобы всегда использовать циклический оп¬ 
рос. Вторым подходом является использование только переключений. Третий ва¬ 
риант состоит в том, чтобы каждый раз принимать отдельное решение. В момент 
принятия решения не известно, что лучше — переключаться или ждать, но в лю¬ 
бой системе можно отследить активность процессов и затем проанализировать ее 
в автономном режиме. При этом можно сказать, какое решение было бы лучшим 
в том или ином случае и сколько процессорного времени было потрачено. Таким 
образом, ретроспективный алгоритм становится эталоном, относительно которо¬ 
го может измеряться эффективность реальных алгоритмов. 

Эта проблема уже изучалась исследователями [173, 172, 255]. В большинстве 
работ используется модель, в которой поток, не заполучивший мьютекс, какое-то 
время опрашивает состояние мьютекса в цикле. Если пороговое значение времени 
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ожидания превышается, он переключается. В некоторых случаях пороговое зна¬ 
чение фиксировано, как правило, оно равно известному времени, требующемуся 
на переключение на другой поток и обратно. В других случаях эта величина меня¬ 
ется динамически, в зависимости от истории состояния ожидаемого мьютекса. 

Лучшие результаты достигались тогда, когда система учитывала несколько по¬ 
следних интервалов ожидания и предполагала, что следующий интервал ожидания 
будет близок по величине к предыдущим. Например, снова предполагая, что пере¬ 
ключение контекста занимает 1 мс, поток будет ожидать в цикле максимум 2 мс, 
но запоминать при этом, сколько времени он на самом деле провел в состоянии 
ожидания. Если ему не удается захватить мьютекс и он видит, что за предыдущие 
три попытки он ждал в среднем 200 мкс, значит, ему следует ждать 2 мс, прежде 
чем переключаться. Однако если он находился в цикле ожидания целые 2 мс в каж¬ 
дую из своих предыдущих попыток, то он должен переключиться немедленно, не 
тратя на ожидание ни одного цикла. Дополнительные детали можно найти в [172]. 

Планирование мультипроцессора 

На однопроцессорной системе планирование одномерно. Единственный вопрос, 
на который должен быть каждый раз получен ответ, — какой процесс должен быть 
запущен следующим? На мультипроцессоре планирование двумерно. Планировщик 
должен решить, какой процесс и на котором центральном процессоре запустить. 
Это дополнительное измерение существенно усложняет планирование на мульти¬ 
процессорах. 

Другой усложняющий фактор состоит в том, что в некоторых системах все про¬ 
цессы являются независимыми, тогда как в других системах они формируют груп¬ 
пы. Примером первой ситуации является система реального времени, в которой 
независимые пользователи запускают независимые процессы. Эти процессы не 
связаны друг с другом, и планирование каждого из них не зависит от остальных 
процессов. 

Пример второй ситуации часто встречается в среде разработки программ. Боль¬ 
шие системы, как правило, состоят из некоторого количества заголовочных фай¬ 
лов, содержащих макросы, определения типов и объявления переменных, исполь¬ 
зуемых в собственно файлах программы. При изменении заголовочного файла все 
программные файлы, в которые он включен, должны быть перекомпилированы. 
Для этого обычно используется программа таке. При вызове программа таке на¬ 
чинает компиляцию только тех файлов, которые должны быть перекомпилирова¬ 
ны из-за изменений самих файлов или заголовочных файлов, включенных в эти 
файлы кода. Все еще имеющие силу объектные файлы заново не пересоздаются. 

Оригинальная версия программы таке выполняла свою работу последователь¬ 
но, но новые версии, созданные для мультипроцессоров, могут начинать всю ком¬ 
пиляцию одновременно. Если требуется откомпилировать 10 файлов, то нет смыс¬ 
ла выполнить компиляцию 9 файлов быстро, а последний файл отложить на потом, 
так как пользователь будет считать работу выполненной только по завершении 
компиляции последнего файла. В этом случае есть смысл рассматривать все эти 
процессы как группу и учитывать это при их планировании. 
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Разделение времени 

Рассмотрим сначала случай планирования независимых процессов. Затем мы об¬ 
судим, как планировать зависимые процессы. Простейший алгоритм планирова¬ 
ния независимых процессов (или потоков) состоит в поддержании единой струк¬ 
туры данных для готовых процессов, возможно, просто списка, но скорее всего 
множества списков для процессов с различными приоритетами (рис. 8.12, а). Здесь 
все 16 центральных процессоров в данный момент заняты, а 14 процессов с раз¬ 
личными приоритетами ожидают запуска. Первым заканчивает работу (или его 
процесс блокируется) центральный процессор 4. При этом он блокирует очередь 
планирования и выбирает из нее процесс с наивысшим приоритетом, то есть 
процесс Л (рис. 8.12, б). Затем освобождает центральный процессор 12 и выбира¬ 
ет процесс В (рис. 8.12, ѳ). Пока эти процессы независимы, подобное планирова¬ 
ние представляет собой разумный выбор. 
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Рис. 8.12. Использование единой структуры данных для планирования мультипроцессора 


Наличие единой структуры данных планирования, используемой всеми цент¬ 
ральными процессорами, обеспечивает процессорам режим разделения времени 
подобно тому, как это выполняется на однопроцессорной системе. Кроме того, та¬ 
кая организация позволяет автоматически балансировать нагрузку, то есть она 
исключает ситуацию, при которой один центральный процессор простаивает, в то 
время как другие процессоры перегружены. Два недостатка такой схемы представ¬ 
ляют собой потенциальный рост конкуренции за структуру данных планирования 
по мере увеличения числа центральных процессоров и обычные накладные расхо¬ 
ды на выполнение переключения контекста, когда процесс блокируется, ожидая 
выполнения операции ввода-вывода. 

Переключение контекста также может случиться, когда истекает квант про¬ 
цесса. Мультипроцессор обладает определенными свойствами, которыми не обла¬ 
дают однопроцессорные системы. Предположим, что процесс удерживает спин- 
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блокировку, что, как уже говорилось выше, часто встречается на мультипроцессо¬ 
рах. Другие центральные процессоры, ждущие освобождения блокировки, просто 
теряют время в циклах ожидания, пока этот процесс не будет запущен снова и не 
отпустит блокировку. На однопроцессорных системах спин-блокировка применя¬ 
ется редко. Поэтому если процесс, удерживающий мьютекс, блокируется и запу¬ 
скается другой процесс, то при попытке заполучить мьютекс второй процесс будет 
тут же блокирован, и много времени потеряно не будет. 

Чтобы решить данную проблему, в некоторых системах применяется умное 
планирование, в котором процесс, захватывающий спин-блокировку, устанавлива¬ 
ет флаг, демонстрирующий, что он в данный момент обладает спин-блокировкой 
[368]. Когда процесс освобождает блокировку, он также очищает и флаг. Таким 
образом, планировщик не останавливает процесс, удерживающий спин-блокиров¬ 
ку, а, напротив, дает ему еще немного времени, чтобы тот завершил выполнение 
критической области и отпустил мьютекс. 

Другая проблема, играющая важную роль в планировании, заключается в том 
факте, что хотя все центральные процессоры равны, но некоторые центральные 
процессоры равнее других. В частности, когда процесс А достаточно долго работает 
на центральном процессоре к, кэш процессора к будет полон блоками процесса А. 
Если процесс А должен быть снова вскоре запущен, его производительность мо¬ 
жет оказаться выше, если он будет запущен снова на центральном процессоре к, 
так как кэш процессора & может все еще содержать некоторые блоки процесса Л. 
Наличие блоков в кэше увеличит частоту попаданий кэша и, таким образом, уве¬ 
личит скорость выполнения процесса. Кроме того, ТЬВ также может содержать 
правильные страницы, что снизит количество прерываний из-за ошибок ТЬВ. 

Некоторые мультипроцессоры учитывают данные соображения и используют 
так называемое родственное планирование [342]. Основная идея данного метода 
заключается в приложении серьезных усилий для того, чтобы процесс был запу¬ 
щен на том же центральном процессоре, что и в прошлый раз. Один из способов 
реализации этого метода состоит в использовании двухуровневого алгоритма пла¬ 
нирования. В момент создания процесс назначается конкретному центральному 
процессору, например наименее загруженному в данный момент. Это назначение 
процессов процессорам представляет собой верхний уровень алгоритма. В резуль¬ 
тате каждый центральный процессор получает свой набор процессов. 

Действительное планирование процессов находится на нижнем уровне алгорит¬ 
ма. Оно выполняется отдельно каждым центральным процессором при помощи 
приоритетов или других средств. Старания удерживать процессы на одном и том 
же центральном процессоре максимизируют родственность кэша. Однако если 
у какого-либо центрального процессора нет работы, у загруженного работой про¬ 
цессора отнимается процесс и отдается ему. 

Двухуровневое планирование обладает тремя преимуществами. Во-первых, оно 
довольно равномерно распределяет нагрузку среди имеющихся центральных про¬ 
цессоров. Во-вторых, двухуровневое планирование по возможности использует 
преимущество родственности кэша. В-третьих, поскольку у каждого центрально¬ 
го процессора при таком варианте планирования есть свой собственный список 
свободных процессов, конкуренция за списки свободных процессов минимизи¬ 
руется, так как попытки использования списка другого процессора происходят 
относительно нечасто. 
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Совместное использование пространства 

Другой подход к планированию мультипроцессоров может быть использован, если 
процессы связаны друг с другом каким-либо способом. Ранее уже обсуждался при¬ 
мер параллельного выполнения процедуры таке. Часто также случается, что один 
процесс создает множество потоков, работающих совместно. Для нашей задачи 
задание, состоящее из нескольких связанных процессов или процесс, состоящий 
из нескольких потоков ядра, представляют собой, по сути, одно и то же. Мы будем 
называть планируемые объекты потоками, но все сказанное здесь в равной мере 
справедливо и для процессов. Планирование нескольких потоков на нескольких 
центральных процессорах называется совместным использованием пространства 
или разделением пространства. 

Простейший алгоритм разделения пространства работает следующим образом. 
Предположим, что сразу создается целая группа связанных потоков. В момент их 
создания планировщик проверяет, есть ли свободные центральные процессоры по 
количеству создаваемых потоков. Если свободных процессоров достаточно, каж¬ 
дому потоку выделяется собственный (то есть работающий в однозадачном режи¬ 
ме) центральный процессор и все потоки запускаются. Если процессоров недо¬ 
статочно, ни один из потоков не запускается, пока не освободится достаточное 
количество центральных процессоров. Каждый поток выполняется на своем про¬ 
цессоре вплоть до завершения, после чего все центральные процессоры возвраща¬ 
ются в пул свободных процессоров. Если поток оказывается заблокированным 
операцией ввода-вывода, он продолжает удерживать центральный процессор, 
который простаивает до тех пор, пока поток не сможет продолжать свою работу. 
При появлении следующего пакета потоков применяется тот же алгоритм. 

В любой момент времени множество центральных процессоров статически раз¬ 
деляется на несколько подмножеств, на каждом из которых выполняются потоки 
одного процесса. На рис. 8.13 показаны подмножества из 4, 6, 8 и 12 процессоров, 
и 2 процессора остались не включенными в подмножества. Со временем, по мере 
завершения работы одних процессов и появления новых процессов, количество 
и размеры групп центральных процессоров изменяются. 
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Рис. 8.13. Набор из 32 центральных процессоров, разделенный 
на четыре группы, плюс два процессора свободны 


Периодически должны приниматься решения о планировании процессов. В од¬ 
нопроцессорных системах для пакетного планирования применяется хорошо изве- 
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стный алгоритм «кратчайшее задание первое». Подобный алгоритм для мультипро¬ 
цессора представляет собой выбор процесса, для которого требуется наименьшее 
количество циклов процессора, то есть процесса, чье произведение числа цент¬ 
ральных процессоров на время работы минимально. Однако на практике эта ин¬ 
формация редко бывает доступна, поэтому применение такого алгоритма затруд¬ 
нительно. Действительно, исследования показали, что придумать что-либо лучшее 
простого обслуживания заданий в порядке их поступления трудно [188]. 

В этой простой модели разбиения процессоров на группы процесс просто за¬ 
прашивает определенное количество центральных процессоров и либо сразу полу¬ 
чает их, либо ждет, пока они не освободятся. Другой подход состоит в том, чтобы 
активно управлять степенью распараллеливания процессов. Один из способов 
управления степенью распараллеливания заключается в наличии центрального 
сервера, ведущего учет работающих и желающих работать процессов, а также 
минимального и максимального количества требующихся для них центральных 
процессоров [332]. Периодически каждый центральный процессор опрашивает 
центральный сервер, чтобы узнать, сколько центральных процессоров он может 
использовать. Затем он увеличивает или уменьшает количество процессов или 
потоков, стараясь добиться соответствия числу доступных процессоров. Напри¬ 
мер, на \ѵеЬ-сервере могут параллельно работать 1, 2, 5, 10, 20 или любое другое 
количество потоков. Если на нем в настоящий момент работает 10 потоков и вдруг 
спрос на центральные процессоры повышается, то ему могут приказать сократить 
число своих потоков до 5. Поэтому, когда 5 потоков закончат свою работу, они не 
получают новую работу, а завершаются. Такая схема обеспечивает динамическое 
изменение размеров групп процессоров, чтобы добиться лучшего соответствия 
текущей нагрузке, нежели фиксированная система на рис. 8.13. 

Бригадное планирование 

Очевидное преимущество разделения пространства заключается в устранении 
многозадачности, что снижает накладные расходы по переключению контекста. 
Однако ее недостаток состоит в потерях времени при блокировке центрального 
процессора. Поэтому проводились активные поиски алгоритма, пытающегося пла¬ 
нировать одновременно в пространстве и времени, особенно для процессов, созда¬ 
ющих большое количество потоков, которым, как правило, требуется возможность 
общения друг с другом. 

Чтобы понять, какие возможны проблемы при независимом планировании по¬ 
токов процесса (или процессов задания), рассмотрим систему с потоками Л 0 и А и 
принадлежащими процессу Л, и потоками В 0 и В и принадлежащими процессу В. 
Потоки Л 0 и В 0 работают в режиме разделения времени на центральном процессо¬ 
ре 0, а потоки А, и В, — на процессоре 1. Потокам Л 0 и А , нужно часто обменивать¬ 
ся информацией. Общение потоков выглядит следующим образом. Поток А 0 по¬ 
сылает потоку Л, сообщение, после чего поток Л, отправляет потоку Л 0 ответ и т. д. 
Предположим, что потоки Л 0 и В, начали выполняться первыми, как показано на 
рис. 8.14. 

В интервале времени 0 поток Л 0 посылает потоку Л, запрос, но поток Л, не по¬ 
лучает его до тех пор, пока не будет запущен в интервале времени 1, начинающем- 
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ся через 100 мс. Он немедленно отправляет ответ, но поток А 0 не получает ответа, 
пока его снова не запустят в момент времени 200 мс. В результате за 200 мс мы 
получаем всего одну пару запрос-ответ, что не слишком хорошо. 

Работает поток Ад 



Рис. 8.14. Общение двух работающих в противофазе потоков, принадлежащих процессу А 

Решением данной проблемы является так называемое бригадное планирование, 
представляющее собой развитие идеи совместного планирования [255]. Бригад¬ 
ное планирование состоит из трех частей: 

1. Группы связанных потоков планируются как одно целое, бригада. 

2. Все члены бригады запускаются одновременно, на разных центральных про¬ 
цессорах с разделением времени. 

3. Все члены бригады начинают и завершают свои временные интервалы вместе. 

Бригадное планирование работает благодаря синхронности работы всех цент¬ 
ральных процессоров. Это значит, что время разделяется на дискретные кванты, 
как было показано на рис. 8.14. В начале каждого нового кванта все центральные 
процессоры перепланируются заново, и на каждом процессоре запускается новый 
поток. В начале следующего кванта опять принимается решение о планировании. 
В середине кванта планирование не выполняется. Если какой-либо поток блоки¬ 
руется, его центральный процессор простаивает до конца кванта времени. 

Пример работы бригадного планирования приведен на рис. 8.15. Здесь показан 
мультипроцессор с шестью процессорами, на которых работают пять процессов, 
от А до Е, с общим числом потоков, равным 24. В течение временного интервала 0 
потоки от А 0 до А 6 планируются и выполняются. Во время интервала 1 планируют¬ 
ся и выполняются потоки В {) , В и В 2 , С 0 , С и и С,. В течение временного интервала 2 
планируются и выполняются пять потоков процесса Б и поток Е 0 . Оставшиеся 
шесть потоков процесса Е работают во время интервала 3. Затем цикл повторяется, 
так что временной интервал 4 повторяет интервал 0 и т. д. 

Идея бригадного планирования состоит в том, чтобы все потоки процесса 
работали по возможности вместе, так, что если один из них посылает сообщение 
другому потоку, то второй поток получает сообщение практически мгновенно 
и может так же быстро на него ответить. На рис. 8.15, поскольку все потоки 
процесса А работают вместе в течение одного кванта времени, они могут отправ¬ 
лять и принимать большое количество сообщений за один квант времени, устра¬ 
няя, таким образом, проблему рис. 8.14. 
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Рис. 8.15. Бригадное планирование 


Многомашинные системы 

Привлекательность и популярность мультипроцессоров связана с тем, что они 
предлагают простую коммуникативную модель: все центральные процессоры про¬ 
сто совместно используют общую память. Процессы могут писать в память сооб¬ 
щения, которые затем могут считываться другими процессами. Синхронизация 
может выполняться при помощи мьютексов, семафоров, мониторов и других хо¬ 
рошо разработанных методов. Единственная ложка дегтя в бочке меда заключает¬ 
ся в том, что большие мультипроцессоры сложны в построении и поэтому дороги. 

Для решения этой проблемы большое количество исследований было посвя¬ 
щено многомашинным системам или мультикомпьютерам, представляющим 
собой тесно связанные центральные процессоры, у которых нет общей памяти. 
У каждого из них имеется своя отдельная оперативная память, как было показано 
на рис. 8.1, б. У этих систем есть множество других названий, включая кластер¬ 
ные компьютеры и СО\Ѵ8 (Сіизіегз о1\Уогкз1;аЦопз — гроздья рабочих станций). 

Создание таких систем не представляет сложности, так как их основными ком¬ 
понентами являются усеченные варианты обычных персональных компьютеров с 
добавлением сетевой интерфейсной карты. Разумеется, секрет достижения высо¬ 
кой производительности кроется в грамотной схеме соединительной сети и интер¬ 
фейсной карты. Эта проблема полностью аналогична проблеме создания общей 
памяти в мультипроцессоре. Однако в многомашинных системах целью является 
передача сообщений за микросекунды, а не доступ к памяти за наносекунды, 
поэтому эта задача проще и, соответственно, ее решение является более простым 
и дешевым в реализации. 

В следующих разделах мы сначала кратко рассмотрим аппаратное обеспечение 
многомашинных систем, особенно аппаратное обеспечение соединительной сети. 
После этого мы перейдем к обсуждению программного обеспечения, сначала низко¬ 
уровневых коммуникационных программ, а затем высокоуровневого программного 
обеспечения связи. Мы также обсудим способы программной реализации совмест¬ 
но используемой памяти в системах, у которых нет аппаратной общей памяти. 
Наконец, мы рассмотрим вопросы планирования и балансировки нагрузки. 
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Аппаратное обеспечение многомашинных систем 

Базовый узел многомашинной системы состоит из центрального процессора, па¬ 
мяти, сетевого интерфейса и иногда жесткого диска. Этот узел может быть упако¬ 
ван в стандартный корпус персонального компьютера, но графический адаптер, 
монитор, клавиатура и мышь у него практически всегда отсутствуют. В некоторых 
случаях такой персональный компьютер может содержать в себе вместо одного 
центрального процессора 2-процессорную или 4-процессорную плату, но для про¬ 
стоты мы будем предполагать, что у каждого узла всего один центральный про¬ 
цессор. Часто для создания многомашинных систем объединяются сотни или даже 
тысячи узлов. Ниже будет кратко рассказано о том, как организовано это аппарат¬ 
ное обеспечение. 

Технология соединений 

У каждого узла есть сетевая интерфейсная карта с выходящими из нее одним или 
двумя кабелями (коаксиальными или оптоволоконными). Эти кабели соединяют¬ 
ся с другими узлами или коммутаторами. В небольшой системе может существо¬ 
вать один коммутатор, к которому присоединяются все узлы, образую топологию 
«звезда» (рис. 8.16, а). Подобная топология применяется в современных комму¬ 
тируемых сетях ЕіЬегпеІ. 
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Рис. 8.16. Различные топологии соединения узлов: один коммутатор (а); кольцо (б); 
решетка (в); двойной тор (г); куб (д); четырехмерный гиперкуб (е) 

Альтернативная топология может представлять собой кольцо, в котором каждый 
узел соединяется с двумя соседними узлами без помощи коммутаторов (рис. 8.16, б). 
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Третий вариант топологии представляет собой решетку или сеть (рис. 8.16, в). 
Это уже двумерная топология, применяемая во многих коммерческих системах. 
Она обладает высокой степенью регулярности и легко масштабируется до больших 
размеров. Топология решетки имеет диаметр, которым называют самый длинный 
путь между двумя узлами. Диаметр решетки увеличивается пропорционально 
квадратному корню от общего числа узлов решетки. Один из вариантов топологии 
решетки, у которой крайние узлы соединены друг с другом, называется двойным 
тором (рис. 8.16, г). Такая схема обладает большей устойчивостью к повреждени¬ 
ям и сбоям, чем простая решетка, к тому же дополнительные линии связи снижа¬ 
ют ее диаметр. 

Топология куб (рис. 8.16, Э) представляет собой регулярную трехмерную то¬ 
пологию. На рисунке изображен куб размером 2x2x2, но на практике применяют¬ 
ся кубы значительно больших размеров. На рис. 8.16, е показан четырехмерный 
куб, созданный из двух трехмерных кубов с помощью соединений соответствую¬ 
щих узлов. Эту идею можно развивать, создавая пяти- и шестимерные кубы и т. д. 
Созданный таким образом и-мерный куб называется гиперкубом. Подобная то¬ 
пология используется во многих параллельных компьютерах, потому что диаметр 
в них растет линейно в зависимости от размерности. Другими словами, диаметр 
представляет собой логарифм по основанию 2 от числа узлов, например, у 10-мер- 
ного гиперкуба с 1024 узлами диаметр будет равен всего 10, в результате чего такая 
схема обладает прекрасными временными характеристиками (низкой задержкой). 
Обратите внимание, что если организовать эти 1024 узла в виде квадратной решет¬ 
ки 32x32, то диаметр в этом случае будет равен 62, что более чем в шесть раз хуже, 
чем для гиперкуба. Платой за небольшой диаметр гиперкуба является большое 
число ответвлений на каждом узле, пропорциональное размерности гиперкуба, 
и, таким образом, большее количество (и большая стоимость) связей между узлами. 

В многомашинных системах применяются две коммутационные схемы. В пер¬ 
вой из них каждое сообщение сначала разбивается (либо программным обеспечени¬ 
ем пользователя, либо сетевым интерфейсом) на отдельные фрагменты, называемые 
пакетами. Коммутационная схема, называемая коммутацией пакетов с промежу¬ 
точным хранением, состоит в том, что пакет сначала посылается сетевой картой 
источника первому узлу (рис. 8.17, а). Пакет передается побитно, и когда прибы¬ 
вает весь пакет, он копируется на следующий коммутатор (рис. 8.17, б). Когда па¬ 
кет прибывает на коммутатор, соединенный с пунктом назначения (рис. 8.17, в), 
пакет копируется на сетевую карту узла-получателя и, наконец, попадает в опера¬ 
тивную память этого узла. 

Хотя схема коммутации пакетов с промежуточным хранением обладает гибко¬ 
стью и эффективностью, у нее есть проблема, заключающаяся в увеличении за¬ 
держки передачи сообщения по сети. Предположим, что время передачи одного 
пакета на один транзитный участок на рис. 8.17 составляет Т нс. Поскольку для 
передачи пакета от центрального процессора 1 до центрального процессора 2 тре¬ 
буется закопировать этот пакет четыре раза (на коммутаторы А, С и И и, наконец, 
узлу-получателю) и ни одна операция копирования не может начаться, пока не 
будет завершена предыдущая, задержка передачи по соединительной сети состав¬ 
ляет 4 Т нс. Один из способов решения данной проблемы заключается в создании 
гибридной сети, обладающей некоторыми свойствами коммутации пакетов и неко- 
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торыми свойствами коммутации каналов. Например, каждый пакет может логи¬ 
чески разбиваться на более мелкие единицы. Как только первая такая единица 
прибывает на коммутатор, она может пересылаться дальше на следующий комму¬ 
татор, прежде чем прибудет остальная часть пакета. 

Входной 



і 

Целый пакет Целый пакет Целый пакет 


Рис. 8.17. Коммутация пакетов с промежуточным хранением 

Другой режим коммутации, коммутация каналов, заключается в том, что пер¬ 
вый коммутатор сначала устанавливает путь через все коммутаторы до коммута¬ 
тора-получателя. Как только путь установлен, биты передаются от источника к 
приемнику без остановок. При этом промежуточного хранения не производится. 
Для коммутации каналов требуется фаза начальной установки, занимающая не¬ 
которое время, зато по завершении этапа установки весь процесс передачи данных 
идет быстрее. Когда сообщение отправлено, путь должен быть снова разорван. 
Существует вариант коммутации каналов, называемый червячной маршрутиза¬ 
цией, при которой каждый пакет разбивается на подпакеты, и первый подпакет 
начинает передаваться еще до того, как был установлен полный путь. 

Сетевые интерфейсы 

У всех узлов многомашинных систем есть плата, на которой расположены все со¬ 
единения узла с соединительной сетью, удерживающей мультикомпьютер вместе. 
Архитектура сетевой платы и способ ее соединения с центральным процессором и 
оперативной памятью оказывают существенное влияние на операционную систе¬ 
му. В данном разделе будут кратко рассмотрены некоторые из этих вопросов. Этот 
материал частично основан на [29]. Кроме того, использовалась следующая лите¬ 
ратура: [49, 257,312, 348]. 

Практически во всех многомашинных системах интерфейсная карта содержит 
некоторое количество ОЗУ для хранения входящих и выходящих пакетов. Как 
правило, выходной пакет должен быть скопирован на интерфейсную плату прежде, 
чем она сможет начать его передачу первому коммутатору. Причина этого состоит 
в том, что многие соединительные сети являются синхронными, поэтому, как толь¬ 
ко начинается передача одного пакета, его биты должны передаваться с постоян- 
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ной скоростью. Если пакет находится в оперативной памяти, постоянство потока 
гарантировать невозможно, поскольку на шине памяти может существовать и дру¬ 
гой трафик. Наличие выделенной памяти в интерфейсной карте устраняет эту про¬ 
блему. Схема из четырех узлов показана на рис. 8.18. 


Узел 1 Узел 2 



Узел 3 интерфейсной интерфейсной Узел 4 

платы платы 

Рис. 8.18. Расположение сетевых интерфейсных плат в мультикомпьютере 

Та же проблема касается приходящих пакетов. Биты прибывают по сети с по¬ 
стоянной и иногда очень высокой скоростью. Если сетевой интерфейс не может 
хранить их в режиме реального времени, по мере прибытия данные будут терять¬ 
ся. Попытка сразу передавать их по системной шине (например, по шине РСІ) 
в оперативную память слишком рискованна. Поскольку сетевая карта, как прави¬ 
ло, подключается к шине РСІ, эта шина представляет собой единственную связь 
сетевой карты с оперативной памятью, и неизбежно соревнование за эту шину 
с диском и другими устройствами ввода-вывода. Спокойнее сохранять приходя¬ 
щие пакеты в независимом ОЗУ сетевой карты, а затем копировать их в оператив¬ 
ную память. 

У интерфейсной платы может быть один или несколько каналов БМА или даже 
целый процессор на плате. Каналы БМА могут копировать пакеты между интер¬ 
фейсной картой и оперативной памятью с большой скоростью, запрашивая блоч¬ 
ную передачу по системной шине. Такой режим позволяет передавать по шине 
несколько слов подряд, не запрашивая шину для каждого слова отдельно. Именно 
для возможности использования такого режима ОЗУ на интерфейсной карте нуж¬ 
но в первую очередь. 

На некоторых интерфейсных картах устанавливается полноценный централь¬ 
ный процессор, к которому, возможно, добавляются один или несколько каналов 
Б МА. Такая схема означает, что основной центральный процессор может перело¬ 
жить часть нагрузки на сетевую карту, например обеспечение надежной передачи 
(при условии, что лежащее в основе аппаратное обеспечение может терять паке¬ 
ты), реализацию многоадресной рассылки (отправка пакетов более чем одному 
адресату) и заботу о защите в системе с несколькими процессами. Однако нали- 
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чие нескольких центральных процессоров означает, что они должны синхронизи¬ 
роваться во избежание конфликтов, что увеличивает сложность системы и озна¬ 
чает больше работы для операционной системы. 


Коммуникационное программное 
обеспечение низкого уровня 

Врагом высокопроизводительной связи в многомашинных системах является из¬ 
лишнее копирование пакетов. В лучшем случае происходит одна операция копи¬ 
рования из ОЗУ на интерфейсную плату источника, одна операция копирования 
с интерфейсной платы источника на интерфейсную плату приемника (если про¬ 
межуточное хранение в сети не применяется) и одна операция копирования с ин¬ 
терфейсной платы приемника в оперативную память. Итого три операции копи¬ 
рования. Однако во многих системах ситуация оказывается еще хуже. В частности, 
если интерфейсная карта отображается на память в адресном пространстве ядра, 
а не в адресном пространстве пользователя, процесс пользователя может послать 
пакет, только обратившись к системному вызову, который с помощью эмулиро¬ 
ванного прерывания переключится в пространство ядра. Программам ядра, воз¬ 
можно, потребуется скопировать пакет в свой собственный буфер как при переда¬ 
че, так и при приеме пакета, например, чтобы избежать страничных прерываний 
при передаче по сети. Кроме того, получающее ядро, может статься, не будет знать, 
где разместить пакет, пока оно не изучит содержимое пакета. Эти пять операций 
копирования показаны на рис. 8.18. 

Если производительность главным образом зависит от копирования в ОЗУ и 
из ОЗУ, лишние операции копирования могут удвоить сквозную задержку и вдвое 
снизить пропускную способность. Во избежание такого удара по производитель¬ 
ности во многих мультикомпьютерах применяется отображение интерфейсных 
карт в адресное пространство пользователя. При этом пользовательские процессы 
получают возможность напрямую помещать пакеты в интерфейсную плату, без 
обращения к ядру. Хотя такой подход определенно помогает увеличить произво¬ 
дительность, с его применением связаны две проблемы. 

Во-первых, что если на узле одновременно работает несколько процессов, ко¬ 
торым нужен доступ к сети для отправки пакетов? Какой из них получит интер¬ 
фейсную карту в свое адресное пространство? Использование системного вызова 
для отображения карты на виртуальное адресное пространство является дорогим 
удовольствием, но если один процесс получит интерфейсную карту, то как осталь¬ 
ные процессы смогут получать и отправлять пакеты? И что произойдет, если карта 
будет отображена на виртуальное адресное пространство процесса А, а пакет при¬ 
бывает для процесса В, особенно если у этих процессов разные владельцы и ни 
один из них не хочет пальцем о палец ударить, чтобы помочь другому? 

Одно решение заключается в том, чтобы отобразить интерфейсную карту на все 
процессы, которым она нужна, но тогда потребуется специальный механизм пре¬ 
дотвращения конфликтов. Например, если процесс А получит буфер интерфейс¬ 
ной карты, после чего, поскольку временной интервал работы процесса А закон¬ 
чится, процесс В также получит буфер интерфейсной карты, то результаты будут 
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катастрофическими. Необходим определенный механизм синхронизации доступа 
процессов к интерфейсной карте, но такие механизмы, как мьютексы, работают 
только тогда, когда предполагается сотрудничество процессов. В среде разделения 
времени с многочисленными пользователями, спешащими выполнить свою рабо¬ 
ту, один пользователь может просто захватить мьютекс, связанный с картой, и не 
отдавать его. Отсюда следует вывод, что отображение интерфейсной карты на про¬ 
странство пользователя будет работать только в том случае, когда в каждом узле 
работает лишь по одному пользовательскому процессу или предпринимаются спе¬ 
циальные меры (например, разным процессам предоставляются различные участ¬ 
ки ОЗУ интерфейсной карты). 

Вторая проблема состоит в том, что ядру также может потребоваться доступ к 
интерфейсной карте, например, для доступа к файловой системе на удаленном 
узле. Совместное использование интерфейсной карты ядром и пользователями 
представляет собой неудачную идею даже на основе разделения времени. Пред¬ 
положим, что в то время, пока карта отображается в пространство пользователя, 
прибывает пакет ядра. Или представьте, что пользовательский процесс пошлет 
удаленной машине пакет, притворившись ядром. Отсюда следует вывод, что про¬ 
стейшая схема представляет собой две интерфейсные карты, одна из которых ото¬ 
бражается на пространство пользователя, а вторая отображается на пространство 
ядра и используется операционной системой. Многие многомашинные системы 
действуют именно так. 

Связь между узлом и сетевым интерфейсом 

Другой вопрос заключается в том, как пакеты попадают в интерфейсную карту. 
Самый быстрый способ состоит в использовании микросхемы БМА, размещен¬ 
ной на интерфейсной плате, чтобы просто копировать пакеты в ОЗУ. Недостаток 
этого метода заключается в том, что контроллер ОМА использует не виртуальное, 
а физическое адресное пространство и работает независимо от центрального про¬ 
цессора. Во-первых, хотя процесс пользователя знает виртуальный адрес любого 
пакета, который он хочет отправить, ему, как правило, не известен физический 
адрес. Выполнение системного вызова для преобразования виртуального адреса 
в физический нежелательно, так как целью расположения интерфейсной карты 
в адресном пространстве пользователя была как раз попытка избежать лишних си¬ 
стемных вызовов для каждого отправляемого пакета. 

Кроме того, если операционная система решает заменить страницу памяти в то 
время, как контроллер ОМА копирует в нее пришедший пакет, то это приведет не 
только к потере пакета, но и повреждению данных в памяти. 

Этих проблем можно избежать, фиксируя и освобождая страницы в памяти 
с помощью системных вызовов, запрещая таким образом на время их свопинг. 
Однако обращение к двум системным вызовам для каждого отправляемого пакета 
дорого. Если размер пакетов мал, например 64 байта или меньше, накладные рас¬ 
ходы на фиксацию и открепление каждого буфера практически невозможны. Это 
может быть допустимо для больших пакетов, размером, скажем, 1 Кбайт или боль¬ 
ше. Для промежуточных размеров выбор решения зависит от деталей аппаратно¬ 
го обеспечения [29]. 
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В теории та же проблема возникает при работе контроллера ОМА диска или 
другого устройства, но поскольку для них операционная система назначает свои 
буферы, избежать замещения страниц в системных буферах несложно. В данном 
случае проблема возникает, потому что пользователь настраивает контроллер 
БМА и управляет им, а операционная система не догадывается, что подмена 
страницы может оказаться фатальной. Причина, по которой использование буфе¬ 
ров в ядре оправдано для дискового ввода-вывода, но не для коммуникаций мно¬ 
гомашинной системы, заключается в том, что лишняя задержка в 20 мкс является 
приемлемой для дискового ввода-вывода, но совершенно недопустимой для связи 
между процессами в мультикомпьютере. 

Проблемы БМА можно избежать, если пользовательский процесс сначала 
зафиксирует одну страницу в начале работы и спросит у системы ее физический 
адрес. Исходящие пакеты могут сначала копироваться туда, а затем на сетевую ин¬ 
терфейсную плату, но такая излишняя операция копирования почти так же неже¬ 
лательна, как копирование в ядро. 

По этим причинам самым безопасным методом, как правило, является ис¬ 
пользование программного ввода-вывода, так как любое страничное прерывание 
во время ввода-вывода представляет собой всего лишь обычное страничное пре¬ 
рывание центрального процессора, которое может быть обработано операцион¬ 
ной системой стандартным образом. При возникновении страничного прерывания 
цикл копирования мгновенно останавливается и остается блокированным, пока 
операционная система не обработает страничное прерывание. Более сложная схе¬ 
ма представляет собой использование программного ввода-вывода для небольших 
пакетов и прямого доступа к памяти с фиксацией и откреплением буферов для 
больших пакетов. 

Если у сетевых карт есть свой собственный процессор (как, например, у плат 
фирмы Мугіпеі), то эти процессоры на плате могут использоваться для ускорения 
ввода-вывода. Однако следует избегать конфликтов между процессором на плате 
и центральным процессором. Один из методов избежания конфликтов показан на 
рис. 8.19, где узел 1 отправляет пакеты, а узел 2 получает пакеты, причем эти узлы 
не обязательно общаются друг с другом. Ключевой структурой синхронизации 
данных для отправителя является кольцо передачи, а для получателя — кольцо 
приема. У каждого узла есть оба кольца, так как все узлы и отправляют, и полу¬ 
чают данные. В каждом кольце есть место для п пакетов. Кроме того, для каждо¬ 
го кольца поддерживается битовый массив из п битов, либо отдельно от кольца 
(как на рисунке), либо встроенный в кольцо. Битовый массив содержит информа¬ 
цию о том, которые гнезда кольца действительны в данный момент. 

Когда у отправителя появляется новый пакет для отправки, он сначала проверя¬ 
ет, есть ли свободное гнездо в кольце. Если нет, то он должен ждать, во избежание 
порчи буфера. Если свободное гнездо есть, он копирует в него пакет и устанавли¬ 
вает соответствующий бит в битовом массиве. Закончив свою работу, процессор 
на плате проверяет состояние кольца передачи. Если оно содержит какие-либо 
пакеты, процессор выбирает из них самый старый пакет и передает его. Закончив 
передачу, он очищает соответствующий бит в массиве. Поскольку биты устанав¬ 
ливаются только центральным процессором, а очищаются только процессором на 
плате, конфликта не происходит. Кольцо приема работает аналогично, только 
теперь уже процессор на плате устанавливает бит, сообщая таким образом о при- 
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шедшем пакете, а центральный процессор очищает бит. Это означает, что он ско¬ 
пировал пакет и освободил буфер. 

Кольцо Кольцо Центральный 



массив Интерфейсная 

плата 

Рис. 8.19. Использование колец передачи и приема для координации 
центрального процессора с процессором на плате 

Эта схема может также использоваться даже и без программного ввода-вывода, 
выполняемого центральным процессором. В этом случае кольцо передачи содержит 
не сам пакет, а только указатель на пакет, находящийся в оперативной памяти. 
Когда процессор на плате готов передавать пакет, он забирает его на интерфейс¬ 
ную плату либо с помощью программного ввода-вывода, либо с помощью ЭМ А. 
В обоих случаях этот подход работает только тогда, когда страница, содержащая 
пакет, фиксирована. 


Коммуникационное программное обеспечение 
уровня пользователя 

Процессы на разных центральных процессорах многомашинной системы общают¬ 
ся, отправляя друг другу сообщения. В своем простейшем виде этим обменом сооб¬ 
щениями явно занимаются процессы пользователя. Другими словами, операционная 
система предоставляет способ отправки и получения сообщения, а библиотечные 
процедуры обеспечивают доступность этих системных вызовов для пользователь¬ 
ских процессов. В более сложной форме передача сообщений скрыта от пользовате¬ 
ля под видом вызова удаленной процедуры. Ниже будут рассмотрены оба метода. 

Библиотечные вызовы вепс! и гесеіѵе 

Служба связи может быть минимизирована до двух (библиотечных) вызовов, один 
для отправки сообщений и один для их получения. Формат вызова для отправки 
сообщения может быть, например, таким: 

зепсКсІеБТ. &пріг): 

а вызов для получения сообщения может выглядеть так: 
гесеіѵе(асісіг . &шрГг): 
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Первая процедура посылает сообщение, на которое указывает указатель тріг, 
процессу йезі (идентификатор процесса) и блокирует вызывающий ее процесс до 
тех пор, пока сообщение не будет отправлено. Вторая процедура вызывает блоки¬ 
ровку процесса вплоть до получения сообщения. Когда сообщение приходит, оно 
копируется в буфер, на который указывает тріг, и процесс, вызвавший эту биб¬ 
лиотечную процедуру, разблокируется. Параметр аМг указывает адрес, от кото¬ 
рого вызывающий процесс ожидает прихода сообщения. Возможны различные 
варианты этих двух процедур и их параметров. 

Вопрос состоит в том, как выполняется адресация. Так как мультикомпьютеры 
статичны, с фиксированным числом центральных процессоров, проще всего исполь¬ 
зовать адреса, состоящие из двух частей: номера центрального процессора и номе¬ 
ра процесса или порта на данном центральном процессоре. Тогда каждый цент¬ 
ральный процессор может управлять собственными адресами без конфликтов. 

Блокирующие и неблокирующие вызовы 

Описанные выше вызовы представляют собой блокирующие вызовы (иногда на¬ 
зываемые синхронными вызовами). Когда процесс обращается к процедуре зепсі, 
он указывает адресат и буфер, данные из которого следует послать указанному 
адресату. Пока сообщение посылается, передающий процесс блокирован (то есть 
приостановлен). Команда, следующая за обращением к процедуре зепсі, не выпол¬ 
няется до тех пор, пока все сообщение не будет послано (рис. 8.20, а). Аналогично, 
обращение к процедуре гесеіѵе не возвращает управления, пока сообщение не бу¬ 
дет получено целиком и положено в буфер, адрес которого указан в параметре. 
Процесс остается приостановленным, пока не прибудет сообщение, даже если на 
это уйдет несколько часов. В некоторых системах получатель может указать, от 
кого именно он ожидает прихода сообщения. В этом случае процесс будет блоки¬ 
рован, пока не прибудет сообщение от указанного отправителя. 

Альтернативу блокирующим вызовам составляют неблокирующие вызовы 
(иногда называемые асинхронными вызовами). Если процедура зепсі является 
неблокирующей, то она возвращает управление вызывающему ее процессу прак¬ 
тически немедленно, прежде чем сообщение будет отправлено. Преимущество этой 
схемы состоит в том, что отправляющий процесс может продолжать вычисления 
параллельно с передачей сообщения, что позволяет избежать простоя централь¬ 
ного процессора (при условии, что других готовых к работе процессов нет). Выбор 
между блокирующим и неблокирующим примитивами обычно делается проекти¬ 
ровщиками системы (то есть, как правило, доступен либо один примитив, либо 
другой), хотя в некоторых системах бывают доступны оба примитива и право вы¬ 
бора предоставляется пользователю. 

Однако помимо преимущества высокой производительности, с неблокирующи¬ 
ми примитивами связана более сложная организация программы. Отправителю 
нельзя изменять содержимое буфера сообщения до тех пор, пока это сообщение 
не будет полностью отправлено. Последствия модификации сообщения во время 
его отправки слишком ужасны, чтобы рассказывать о них перед сном. Что еще 
хуже, если у отправляющего процесса нет возможности узнать, что передача уже 
выполнена, то он никогда не будет уверен, можно ли уже пользоваться буфером. 
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Рис. 8.20. Блокирующий вызов процедуры зепсі (а); 
неблокирующий вызов процедуры зепсі (б) 

Возможны три метода решения этой проблемы. Первое решение заключается 
в копировании ядром сообщения в свой буфер, после чего процессу позволяется 
продолжать работу (рис. 8.20, б). С точки зрения отправителя эта схема аналогич¬ 
на блокирующему вызову, так как, как только отправитель получает управление, 
он может снова пользоваться буфером. Разумеется, сообщение еще не будет от¬ 
правлено, но отправителю это не мешает. Недостаток этого метода состоит в необ¬ 
ходимости копирования каждого исходящего сообщения из пространства пользо¬ 
вателя в буфер ядра. Во многих сетевых интерфейсах сообщение все равно будет 
скопировано в аппаратный буфер передачи, поэтому первое копирование пред¬ 
ставляет собой просто потерю времени. Лишняя операция копирования может 
существенно снизить производительность системы. 

Второе решение заключается в прерывании отправителя, когда сообщение будет 
отправлено, чтобы известить его об этом факте. В этом случае операции копиро¬ 
вания не требуется, что сохраняет время, но прерывания на уровне пользователя 
значительно усложняют программы и могут привести к внутренним конфликтам 
в программе, в результате чего такие программы будет почти невозможно отладить. 

Третье решение состоит в том, чтобы копировать содержимое буфера при за¬ 
писи. Буфер помечается как доступный только для чтения до тех пор, пока сооб¬ 
щение не будет отправлено. Если буфер используется повторно прежде, чем будет 
отправлено сообщение, создается копия буфера. Недостаток этого варианта за¬ 
ключается в том, что если только буферу не выделена целиком собственная страни¬ 
ца, операции записи с соседними переменными также будут вызывать копирова¬ 
ние страницы. Кроме того, потребуются дополнительные административные меры, 


Отправитель работает 


Возврат 



Многомашинные системы 


593 


так как теперь отправка сообщения неявно изменяет статус чтения/записи стра¬ 
ницы. Наконец, раньше или позже, страница опять может быть записана, что при¬ 
ведет к появлению еще одной копии страницы. 

Таким образом, у отправителя имеется следующий выбор: 

1. Блокирующая операция зепсі (центральный процессор простаивает во вре¬ 
мя передачи сообщения). 

2. Неблокирующая операция зепсі с копированием (время центрального про¬ 
цессора теряется на создание дополнительной копии). 

3. Неблокирующая операция зепй с прерыванием (усложняет программу). 

4. Копирование при записи (в конечном итоге требуется дополнительная опе¬ 
рация копирования). 

При нормальных условиях первый вариант является лучшим, особенно при 
наличии нескольких потоков. При этом пока один поток блокирован, ожидая отправ¬ 
ки сообщения, остальные потоки могут продолжать работу. Для этого метода также 
не требуется буфера в ядре. Более того, как можно увидеть, сравнивая рис. 8.20, а 
и рис. 8.20, б, передача сообщения занимает меньше времени, если не требуется 
дополнительного копирования. 

Следует отметить, что различными авторами используются различные крите¬ 
рии для того, чтобы отличать синхронные примитивы от асинхронных. Альтерна¬ 
тивная точка зрения заключается в том, что вызов является синхронным, только 
если отправитель блокируется до тех пор, пока не будет отправлено сообщение 
и не будет получено подтверждение [13]. В сфере коммуникаций реального време¬ 
ни синхронность имеет другое значение, что, к сожалению, приводит к путанице. 

Как и зепсі, операция гесеіѵе также может быть блокирующей и неблокирую¬ 
щей. Блокирующий вызов просто приостанавливает процесс до прибытия сооб¬ 
щения. Если на центральном процессоре одновременно работают несколько пото¬ 
ков, то такой подход является наиболее простым. Неблокирующий вызов гесеіѵе 
лишь сообщает ядру, где расположен буфер, и почти сразу же возвращает управ¬ 
ление. При прибытии сообщения для извещения процесса может использоваться 
прерывание. Однако прерывания сложно программировать, к тому же они доволь¬ 
но медленны. Поэтому, возможно, лучшим решением является периодическое об¬ 
ращение к почтовому ящику при помощи процедуры рой (опрос), сообщающей, 
пришли ли какие-либо сообщения. Если есть новые сообщения, получатель мо¬ 
жет забрать их с помощью процедуры §е(_тезза§е (получить сообщение), возвра¬ 
щающей первое прибывшее сообщение. В некоторых системах компилятор может 
сам вставлять вызовы процедуры роіі в соответствующих местах программы, хотя 
определить, как часто следует обращаться к этой процедуре, непросто. 

Еще один вариант заключается в том, что при прибытии сообщения в адресном 
пространстве получающего процесса создается новый поток. Такой поток называ¬ 
ется всплывающим или временным потоком. Он выполняет заранее указанную 
процедуру, в качестве параметра которой передается указатель на прибывшее 
сообщение. После обработки сообщения этот процесс просто прекращает свое 
существование. 




594 


Глава 8. Многопроцессорные системы 


Вариантом этой идеи является запуск программы получателя прямо в обработ¬ 
чике прерываний, что позволяет избежать хлопот с созданием временного потока. 
Чтобы еще ускорить эту схему, в само сообщение можно включить адрес обработ¬ 
чика, поэтому, когда оно прибудет, обработчик будет вызван с помощью всего не¬ 
скольких команд процессора. Большой выигрыш данной схемы заключается в том, 
что копирование вообще не нужно. Обработчик получает сообщение от интерфейс¬ 
ной платы и обрабатывает его на лету. Такая схема называется активными сооб¬ 
щениями [348]. Поскольку каждое сообщение содержит адрес обработчика, такая 
схема может работать только в том случае, когда отправители и получатели пол¬ 
ностью доверяют друг другу. 

Вызов удаленной процедуры 

Хотя модель передачи сообщений предоставляет удобный способ структурирова¬ 
ния операционной системы многомашинной системы, у нее есть один существен¬ 
ный недостаток: связь между процессами построена на парадигме ввода-вывода. 
Процедуры $епй и гесеіѵе занимаются вводом-выводом, а многие программисты 
считают ввод-вывод неверной моделью программирования. 

Эта проблема известна уже Давно, но мало что делалось в этом направлении 
вплоть до выхода статьи Биррелла и Нельсона [33], в которой был предложен 
принципиально другой способ решения данной проблемы. Хотя сама идея доволь¬ 
но проста (после того, как кто-то другой уже нашел решение), последствия ее реа¬ 
лизации иногда не совсем очевидны. В данном разделе мы рассмотрим концепцию, 
ее реализацию, обсудим ее достоинства и недостатки. 

В двух словах, то, что предложили Биррелл и Нельсон, заключалось в разреше¬ 
нии программам вызывать процедуры, расположенные на других машинах. Когда 
процесс на машине 1 вызывает процедуру на машине 2, вызывающий процесс на 
машине 1 приостанавливается, а на машине 2 выполняется вызванная процедура. 
Информация между вызывающим процессом и вызываемой процедурой может 
передаваться через параметры, а также возвращаться в результате процедуры. Про¬ 
граммисту не видны ни передача сообщений, ни операции ввода-вывода. Такая 
техника, называемая вызовом удаленной процедуры (КРС, Кетоіе Ргосейиге 
Саіі), стала основой большого количества программного обеспечения для мно¬ 
гомашинных систем. Традиционно вызывающую процедуру называют клиентом, 
а вызываемую — сервером. Мы также будем использовать эту терминологию. 

Идея удаленного вызова процедуры заключается в том, что вызов удаленной 
процедуры должен выглядеть максимально похоже на вызов локальной процеду¬ 
ры. В простейшей форме для вызова удаленной процедуры клиентская программа 
должна быть сцяэана с небольшой библиотечной процедурой, называемой клиент¬ 
ским суррогатом или клиентской заглушкой, представляющей серверную проце¬ 
дуру в адресном пространстве клиента. Аналогично, сервер связан с процедурой, 
называемой серверным суррогатом или серверной заглушкой. Эти процедуры 
создают видимость локальности вызова. 

Фактические этапы выполнения вызова удаленной процедуры показаны на 
рис. 8.21. Суррогаты на рисунке затенены серым цветом. Шаг 1 состоит в обраще- 
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нии клиента к клиентскому суррогату. При этом параметры передаются через стек, 
как при обычном вызове. На шаге 2 клиентский суррогат упаковывает параметры 
в сообщение и обращается к системному вызову для оправки сообщения. Упаковка 
параметров называется маршалингом или маршализацией. На шаге 3 ядро посыла¬ 
ет сообщение с клиентской машины на сервер. На шаге 4 ядро серверной машины 
передает полученное сообщение серверному суррогату (который уже ожидает 
прихода сообщения). Наконец, на шаге 5 серверный суррогат вызывает серверную 
процедуру. Ответ проходит по тому же пути в обратном направлении. 


Клиентский Серверный 

центральный процессор центральный процессор 



Ключевой вопрос, на который следует здесь обратить внимание, состоит в том, 
что клиентская процедура, написанная пользователем, выполняет нормальный (то 
есть локальный) процедурный вызов клиентского суррогата. Так как клиентская 
процедура и клиентский суррогат находятся в одном адресном пространстве, пара¬ 
метры передаются обычным образом. Аналогично, серверная процедура вызыва¬ 
ется процедурой в своем адресном пространстве. Таким образом, вместо выполне¬ 
ния ввода-вывода с помощью процедур $епй и гесеіѵе , связь с удаленными объектами 
осуществляется при помощи имитации нормальных процедурных вызовов. 

Вопросы реализации 

Несмотря на концептуальную элегантность вызова удаленной процедуры, данный 
метод содержит множество незаметных на первый взгляд проблем. Одна из них 
заключается в использовании указателей в качестве параметров. В нормальных 
условиях передача указателя в качестве параметра не представляет проблемы. 
Вызываемая процедура может использовать параметр тем же способом, что и про¬ 
цесс, вызывающий процедуру, поскольку обе процедуры находятся в одном вир¬ 
туальном адресном пространстве. При использовании вызова удаленной процеду¬ 
ры передача указателя невозможна, так как клиент и сервер находятся в различных 
адресных пространствах. 

В некоторых случаях указатели могут передаваться при помощи специальных 
ухищрений. Предположим, что первый параметр представляет собой указатель на 
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целое число к. Клиентский суррогат может упаковать само число к в сообщение 
и передать его серверу. Затем серверный суррогат создает указатель на число к 
и передает его серверной процедуре, как и ожидалось. Когда серверная процедура 
возвращает управление серверному суррогату, тот оправляет число к назад клиен¬ 
ту, где новое число к копируется поверх старого. В результате стандартная пере¬ 
дача параметров по ссылке была заменена передачей значений. К сожалению, этот 
метод не всегда работает, например не работает в том случае, когда указатель ука¬ 
зывает на какую-либо сложную структуру. По этой причине на параметры удален¬ 
ных процедур должны быть наложены определенные ограничения. 

Вторая проблема заключается в том, что в языках со слабым контролем типов, 
таких как С, вполне допустимо написание процедуры, вычисляющей скалярное 
произведение двух векторов (массивов), без указания размеров векторов. Масси¬ 
вы могут, например, ограничиваться специальным символом, известным только 
вызывающей и вызываемой процедурам. При такой ситуации клиентский сурро¬ 
гат не способен корректно упаковать в сообщение все необходимые параметры, так 
как у него нет способа определить их размеры. 

Третья проблема состоит в том, что типы параметров не всегда могут быть точ¬ 
но определены, даже из формального описания самой программы. Так, например, 
процедура ргіпі/ может иметь произвольное количество параметров (по меньшей 
мере, один), которые могут быть произвольной смесью целых и вещественных 
чисел, переменных и констант типа зЬогГ, 1оп§, символьных и строковых перемен¬ 
ных и констант произвольной длины, а также других типов. Вызов ргіпі/ как уда¬ 
ленной процедуры практически невозможен, поскольку в языке С разрешено столь 
многое. Однако правило, говорящее, что вызов удаленных процедур может быть 
использован при условии, что вы не программируете на С (или С++), вряд ли най¬ 
дет понимание среди широких масс программистов. 

Четвертая проблема относится к использованию глобальных переменных. При 
нормальных условиях вызывающая и вызываемая процедуры могут общаться, ис¬ 
пользуя, помимо передаваемых параметров, глобальные переменные. Если теперь 
вызываемая процедура перемещается на другую машину, программа не сможет 
работать, так как глобальные переменные окажутся на разных машинах. 

Наличие всех этих проблем не означает, что дело вызова удаленных процедур 
безнадежно. В действительности этот метод широко применяется, но для его кор¬ 
ректной работы необходимо соблюдение определенных ограничений. 

Распределенная память совместного доступа 

Несмотря на привлекательность вызова удаленных процедур, многие программи¬ 
сты все еще предпочитают модель совместно используемой памяти и хотели бы 
применять ее даже на многомашинной системе. Это может показаться удивитель¬ 
ным, но даже при отсутствии общей памяти можно сохранить иллюзию ее наличия 
при помощи техники, называемой Э5М (ОізСгіЬиСесі ЗЬагесі Метогу — распреде¬ 
ленная совместно используемая память) [204, 205]. В Э5М каждая страница на¬ 
ходится в одном из блоков памяти (см. рис. 8.1). У каждой машины есть своя вир¬ 
туальная память и собственные таблицы страниц. Когда центральный процессор 
выполняет команды ШАО и 5АѴЕ в странице, которой у него нет, происходит странич- 
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ное прерывание с передачей управления операционной системе. Операционная си¬ 
стема находит страницу и просит центральный процессор, владеющей ею на дан¬ 
ный момент, выгрузить страницу и переслать ее по соединительной сети. Когда 
страница прибывает, она загружается в память, а команда, вызвавшая страничное 
прерывание, перезапускается. В результате операционная система просто удовлет¬ 
воряет страничное прерывание, но не с локального диска, а по сети с удаленного 
блока памяти. С точки зрения пользователя все это выглядит так, как если бы 
у машины была совместно используемая память. 

Различие между настоящей общей памятью и системой Б5М показано на 
рис. 8.22. На рис. 8.22, а изображена настоящая многомашинная система с аппа¬ 
ратно реализованной общей памятью. На рис. 8.22, б показана система Б8М, реа¬ 
лизуемая операционной системой. Рисунок 8.22, в демонстрирует еще одну 
форму совместно используемой памяти, на этот раз реализованную более высоки¬ 
ми уровнями программного обеспечения. Такой вариант будет рассматриваться 
позднее в этой главе, но на данный момент мы сконцентрируемся на системе ИЗМ. 

Обсудим теперь некоторые подробности работы системы БЗМ. В Э5М адрес¬ 
ное пространство разделяется на страницы, которые распределены между всеми 
узлами системы. Когда центральный процессор обращается к адресу, не являюще¬ 
муся локальным, происходит прерывание и программное обеспечение Б5М добы¬ 
вает страницу, содержащую данный адрес, и перезапускает команду, вызвавшую 
страничное прерывание, которая во второй раз завершается успешно. Эта концепция 
для адресного пространства, состоящего из 16 страниц и четырех узлов, каждый 
из которых способен удерживать пять страниц, проиллюстрирована на рис. 8.23, а. 

В данном примере, если центральный процессор 0 обращается к командам или 
данным на страницах 0, 2, 5 или 9, эти обращения выполняются локально. Обраще¬ 
ния к другим страницам вызывают прерывания. Например, обращение по адресу 
в странице 10 вызовет прерывание с передачей управления программному обес¬ 
печению ОЗМ, которое перемещает страницу 10 от узла 1 узлу 0 (рис. 8.23, б). 

Репликация 

Усовершенствование, способное значительно повысить производительность сис¬ 
темы, состоит в репликации страниц, для которых разрешено только чтение, 
например с текстом программы или константами. Если страница 10 на рис. 8.23 
представляет собой программную секцию, то при обращении к ней центрального 
процессора 0 может быть создана копия, посылаемая на процессор 0, так что па¬ 
мять центрального процессора 1 не изменяется (рис. 8.23, в). Таким образом, цен¬ 
тральные процессоры 0 и 1 могут оба обращаться к странице 10 настолько часто, 
насколько это им необходимо, не вызывая в дальнейшем страничных прерываний. 

Другая возможность заключается в том, чтобы реплицировать все страницы, 
а не только страницы с доступом только для чтения. Пока эти страницы только 
читаются, нет никакой разницы между репликацией страниц, которые можно мо¬ 
дифицировать, и страниц, которые модифицировать нельзя. Но как только репли¬ 
цированная страница модифицируется, следует предпринять специальные дей¬ 
ствия во избежание появления двух различных копий одной страницы. Поддержка 
непротиворечивости системы будет обсуждаться в следующих разделах. 
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Рис. 8.22. Различные уровни, на которых может быть реализована совместно используемая память: 
аппаратный (а); операционная система (б); программное обеспечение уровня пользователя (в) 
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Глобальная виртуальная память, состоящая из 16 страниц 
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Рис. 8.23. Страницы адресного пространства, распределенные между машинами (а); 
центральный процессор 0 обратился к странице 10(6); если страница 10 доступна 
только для чтения, то используется репликация (а) 

Ложное совместное использование памяти 

Системы 05М во многом напоминают многомашинные системы. В обеих систе¬ 
мах при обращении к слову нелокальной памяти блок памяти, содержащий это 
слово, берется с текущего местоположения и помещается на машину, с которой 
было произведено обращение. Важный вопрос заключается в том, насколько боль¬ 
шим должен быть этот блок памяти? В многомашинных системах размер блока 
кэша, как правило, составляет 32 или 64 байта, чтобы не оказывать слишком боль¬ 
шой нагрузки на шину. В системах ОЗМ размер передаваемого по сети блока па¬ 
мяти должен быть кратен размеру страницы (так как диспетчер памяти работает 
со страницами). Подобная работа имитирует страницы большего размера. 
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У большего размера страниц в системе 05М есть как преимущества, так и не¬ 
достатки. Основное преимущество заключается в том, что время, требуемое для 
переноса по сети 4096 байт, не намного больше, чем для переноса 1024 байт, так 
как существенное время тратится на подготовку этого процесса. Увеличивая пере¬ 
даваемые по сети блоки, часто можно уменьшить количество передаваемых блоков. 
Это свойство особенно важно, так как многие программы обладают локальностью 
ссылок, а это означает, что если программа обратилась к какому-нибудь слову на 
странице, то велика вероятность, что в ближайшем будущем она обратится также 
и к другим словам на этой же странице. 

С другой стороны, блоки памяти больших размеров будут дольше передавать¬ 
ся по сети, блокируя страничные прерывания других процессов. Кроме того, слиш¬ 
ком большой размер логических страниц вызывает новую проблему, называемую 
ложным совместным использованием (рис. 8.24). Здесь на одной странице содер¬ 
жатся две не имеющие друг к другу отношения переменные, А и В. Процессор 1 
часто пользуется переменной Л, читая и записывая ее. А процессор 2 часто ис¬ 
пользует переменную В. В такой ситуации страница, содержащая обе переменные, 
будет постоянно путешествовать от одной машины к другой. 


Центральный Центральный 

процессор 0 процессор 0 


Совместно 

используемая 

страница 



Рис. 8.24. Ложное совместное использование страницы, 
содержащей две несвязанные переменные 


Данная проблема заключается в том, что хотя эти переменные и не связаны 
друг с другом, они оказались на одной странице, поэтому когда какой-либо про¬ 
цесс использует одну из этих переменных, он вместе с ней получает и другую. Чем 
больше эффективный размер страницы, тем выше вероятность ложного совмест¬ 
ного использования памяти, и наоборот — чем меньше эффективный размер стра¬ 
ницы, тем реже будет возникать подобная ситуация. В обычной системе виртуаль¬ 
ной памяти нет ничего подобного данному феномену. 

Умные компиляторы, понимающие суть данной проблемы, стараются поме¬ 
щать переменные разных процессов в различные страницы, что помогает снизить 
частоту ситуаций ложного совместного использования памяти и увеличить про¬ 
изводительность. Однако сказать это легче, чем сделать. Более того, если ситуа¬ 
ция ложного совместного использования заключается в том, что узел 1 использу¬ 
ет один элемент массива, а узел 2 — другой элемент того же массива, то даже умный 
компилятор не сможет устранить эту проблему. 
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Последовательная непротиворечивость 

Если модифицируемые страницы не реплицируются, поддержание непротиворе¬ 
чивости системы не представляет проблем. У каждой модифицируемой страницы 
есть ровно одна копия, которая динамически перемещается по мере надобности от 
одного узла к другому. Поскольку не всегда есть возможность заранее предсказать, 
какая страница будет модифицироваться, во многих системах 05 М при попытке 
процессом прочитать удаленную страницу создается локальная копия. При этом 
обе копии отмечаются в своих диспетчерах памяти как доступные только для чте¬ 
ния. Пока все процессы обращаются к этим страницам только для чтения, ника¬ 
ких проблем не возникает. 

Однако как только какой-либо процесс пытается записать реплицированную 
страницу, возникает потенциальная проблема непротиворечивости, потому что 
изменение только одной копии неприемлемо. Эта ситуация подобна тому, что про¬ 
исходит в многомашинной системе, когда один центральный процессор пытается 
модифицировать слово, присутствующее в нескольких кэшах. В данном случае 
решение заключается в том, что центральный процессор, собирающийся выпол¬ 
нить запись, сначала подает на шину сигнал, сообщающий всем остальным цент¬ 
ральным процессорам, что их копия неверна и ее нужно удалить из блока кэша. 
Система Э5М работает практически так же. Прежде чем общая страница может 
быть записана, всем остальным центральным процессорам, владеющим копией 
этой страницы, посылается сообщение, в котором предлагается выгрузить и анну¬ 
лировать имеющуюся у них страницу. Когда все центральные процессоры ответят 
на это сообщение, оригинальный центральный процессор может выполнить опе¬ 
рацию записи. 

Другой способ поддержать наличие нескольких копий модифицируемых стра¬ 
ниц заключается в использовании мьютексов. Чтобы получить возможность писать 
в какую-либо часть виртуального пространства, процесс должен сначала получить 
мьютекс. После этого процесс может читать и писать в эту память столько раз, 
сколько это ему необходимо. Когда блокировка отпускается, изменения распрост¬ 
раняются на другие копии. До тех пор пока только один центральный процессор 
может получить блокировку для записи в страницу, такая схема обеспечивает не¬ 
противоречивость данных. 

Альтернативный метод состоит в том, что при первой записи в страницу созда¬ 
ется ее копия, которая сохраняется на центральном процессоре, выполняющем за¬ 
пись. Когда другой центральный процессор на удаленной машине пытается полу¬ 
чить блокировку к этой странице, процессор, писавший в эту страницу раньше, 
сравнивает текущее состояние этой страницы с чистым оригиналом и отсылает 
этому центральному процессору список изменений страницы. Таким образом, 
второй процессор вместо аннулирования страницы может обновить ее [178]. 

Планирование многомашинных систем 

На мультипроцессоре все процессы располагаются в общей памяти. Когда какой- 
либо центральный процессор завершает текущее задание, он выбирает процесс 
и запускает его. В принципе все процессы являются потенциальными кандидата¬ 
ми. В многомашинной системе ситуация в корне отличается. У каждого узла есть 
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своя собственная память и свой собственный набор процессов. Центральный про¬ 
цессор 1 не может внезапно решить запустить процесс, расположенный на узле 4, 
не приложив для этого достаточно усилий. Это отличие означает, что планирова¬ 
ние на многомашинной системе реализуется проще, но распределение процессов 
между узлами представляет собой более важную задачу. Ниже мы обсудим эти 
вопросы. 

Планирование многомашинной системы похоже на планирование мульти¬ 
процессора, но не все рассматривавшиеся ранее алгоритмы планирования од¬ 
ной системы применимы к другой системе. Однако простейший мультипроцес¬ 
сорный алгоритм — учет всех готовых процессов в едином централизованном 
списке — не будет работать в многомашинной системе, так как каждый процесс 
может работать только на том центральном процессоре, на котором он распо¬ 
ложен в данный момент. Тем не менее при создании нового процесса можно 
выбрать центральный процессор, на котором он будет работать, например, чтобы 
сбалансировать нагрузку. 

Поскольку у каждого узла есть свои процессы, можно использовать любой ло¬ 
кальный алгоритм планирования. Однако возможно применение бригадного пла¬ 
нирования так же, как оно используется на мультипроцессоре, потому что для него 
требуется всего лишь изначальное принятие решения о том, какой процесс в кото¬ 
ром интервале времени будет работать, и некий способ синхронизации начала всех 
временных интервалов. 

Балансировка нагрузки 

О планировании многомашинных систем можно сказать не так уж и много, пото¬ 
му что как только процесс назначается какому-либо узлу, может использоваться 
любой локальный алгоритм планирования. Однако именно потому, что так мало 
можно сделать после того, как процесс уже назначен узлу, решение о выборе узла 
представляет такую важность. В этом основное отличие многомашинных систем 
от мультипроцессоров, в которых все процессы работают в одной памяти и могут 
переключаться на любой центральный процессор уже во время исполнения. Соот¬ 
ветственно, следует определить, как назначать процессы узлам, чтобы при этом 
повысить эффективность системы. Алгоритмы и эвристики для назначения про¬ 
цессов узлам называются алгоритмами распределения процессоров. 

За несколько лет было разработано большое количество алгоритмов распреде¬ 
ления процессоров (то есть узлов). Различаются они тем, что предполагается из¬ 
вестным в том или ином алгоритме и чего требуется достичь. К известным свой¬ 
ствам процессов относятся процессорные требования, количество памяти и объем 
обмена информацией с другими процессами. Возможные задачи включают ми¬ 
нимизацию потерянного процессорного времени, вызванного отсутствием ло¬ 
кальной работы, минимизацию суммарного сетевого трафика, а также гарантиро¬ 
вание справедливого распределения ресурсов для пользователей и процессов. 
Ниже будут рассмотрены некоторые алгоритмы, позволяющие получить представ¬ 
ление об этих возможностях. 
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Детерминистический графовый алгоритм 

Хорошо изучен класс алгоритмов для систем, состоящих из процессов с известны¬ 
ми требованиями к центральному процессору и памяти, а также матрицей извест¬ 
ных объемов обмена данными между каждой парой процессов. Если количество 
процессов больше количества центральных процессоров, то некоторые процессы 
должны быть назначены каждому процессору. Идея заключается в том, чтобы ми¬ 
нимизировать сетевой трафик. 

Система может быть представлена в виде взвешенного графа, каждая вершина 
которого представляет собой процесс, а каждая дуга — поток сообщений между 
двумя процессами. Математически проблема сводится к тому, чтобы найти спо¬ 
соб разбиения графа на к непересекающихся подграфов при определенных огра¬ 
ничениях, накладываемых на подграфы (например, суммарные требования цент¬ 
ральных процессоров и памяти для подграфа не должны превышать некоторого 
установленного предела). Для каждого решения, удовлетворяющего требованиям, 
дуги, находящиеся целиком внутри подграфа, представляют внутримашинный 
обмен информацией и могут игнорироваться. Дуги, идущие от одного подграфа 
к другому, представляют сетевой трафик. Цель состоит в том, чтобы найти такой 
вариант разбиения графа на подграфы, который минимизирует сетевой трафик 
при выполнении всех требований. Так, на рис. 8.25 показана система из девяти 
процессов от А до I. На дугах отмечены значения сетевой нагрузки между процес¬ 
сами (например, в мегабитах в секунду). 




Рис. 8.25. Два способа распределения девяти процессов на трех узлах 


На рис. 8.25, а граф разделен следующим образом: узлу 1 назначены процессы 
А,ЕиС, на узле 2 работают процессы В,РиН,а узлу 3 достались процессы С, Л и I. 
Общий сетевой трафик представляет собой сумму весов дуг, пересеченных грани¬ 
цами подграфов (показаны штриховыми линиями на рисунке). В данном случае он 
равен 30. На рис. 8.25, б представлен другой вариант разбиения графа на подгра¬ 
фы. При условии, что такой вариант распределения процессов удовлетворяет всем 
требованиям памяти и процессорной мощности, этот выбор лучше, так как при нем 
требуется меньший сетевой трафик. 

Для оптимального разбиения графа на отдельные части следует, видимо, искать 
группы тесно связанных процессов (с высоким уровнем внутригруппового трафи¬ 
ка), но мало взаимодействующие с другими группами (низкий межгрупповой тра¬ 
фик). Данная проблема обсуждается в следующих статьях: [68, 213, 318]. 
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Распределенный эвристический алгоритм, 
инициируемый отправителем 

Рассмотрим теперь некоторые распределенные алгоритмы. При использовании 
одного алгоритма процесс работает на узле, который его создал, если только этот 
узел не перегружен. Перегрузка может оцениваться по числу процессов, их сум¬ 
марной нагрузке на процессор или по какому-либо еще параметру. Если узел ока¬ 
зывается перегружен, он выбирает случайным образом другой узел и запрашивает 
у него данные о его загрузке. Если загрузка данного узла оказывается ниже опре¬ 
деленного уровня, новый процесс отправляется туда [102]. Если данный узел так¬ 
же уже достаточно загружен, выбирается другая машина. Смысл в том, чтобы пе¬ 
регруженные узлы могли попытаться избавится от лишней нагрузки (рис. 8.26, а). 

2 

О 

о. 

<и 



Рис. 8.26. Перегруженный узел ищет легко загруженный узел, которому 
можно передать процесс (а); пустой узел ищет работу (б) 


Авторы статьи, на которую мы ссылались выше, создали для данного алгорит¬ 
ма аналитическую модель очередей. С помощью этой модели было установлено, 
что алгоритм хорошо работает и обладает устойчивостью в широком диапазоне 
параметров, к которым относятся различные пороговые величины и значения сто¬ 
имости переноса данных. 

Тем не менее следует отметить, что в условиях сильной загруженности все ма¬ 
шины будут постоянно посылать другим машинам запросы об их загрузке в тщет¬ 
ной попытке найти кого-нибудь, кто согласится взять у них часть работы. Мало 
кому из процессов удастся уменьшить свою нагрузку, но сами попытки поиска 
помощников могут оказать существенную дополнительную нагрузку на сеть. 

Распределенный эвристический алгоритм, 
инициируемый получателем 

Существует алгоритм, схожий с вышеописанным, но в котором передача процесса 
менее загруженной машине инициируется получателем, то есть менее загруженной 
машиной (см. рис. 8.26, а). Когда завершается очередной процесс, при таком алго- 
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ритме система проверяет, достаточно ли у нее работы. Если нет, она случайным 
образом выбирает машину и просит у нее работу. Если этой машине нечего пред¬ 
ложить, проверяется другая машина, затем третья и т. д. Если за N попыток работу 
найти не удалось, узел временно прекращает поиск, выполняет любую работу, ко¬ 
торая у него есть, после чего весь цикл повторяется после завершения очередного 
процесса. Если работы у узла не остается совсем, он простаивает некоторое время, 
а спустя определенный интервал времени снова принимается искать работу. 

Преимущество этого алгоритма заключается в том, что он не оказывает до¬ 
полнительной нагрузки на сеть в критический период. Предыдущий алгоритм 
обращался с новыми запросами в сеть как раз тогда, когда загрузка узлов и сети 
была и без того высока. В данной схеме вероятность появления незагруженной 
машины в перегруженной системе мала. Однако если такое вдруг случается, 
простаивающая машина легко найдет себе работу в такой ситуации. Конечно, ког¬ 
да почти вся система простаивает, алгоритм, в котором инициатором выступает 
получающая сторона, создает существенный трафик поиска работы. И все же 
значительно лучше иметь накладные расходы в недогруженной системе, чем в пе¬ 
регруженной. 

Возможна комбинация обоих алгоритмов, в которой машины будут пытаться 
избавиться от лишней работы и получить работу, когда ее не хватает. Более того, 
машины, вероятно, могут улучшить эффективность случайного опроса, храня исто¬ 
рию последних попыток и определяя машины, страдающие от хронической пере¬ 
грузки или, наоборот, недогруженности. В зависимости от того, хочет ли инициа¬ 
тор запроса получить работу или избавиться от нее, он может попытаться связаться 
в первую очередь с одной из таких машин. 

Алгоритм торгов 

Другой класс алгоритмов пытается превратить компьютерную систему в некое 
подобие миниатюрной экономики, с продавцами и покупателями услуг и ценами, 
устанавливаемыми спросом и предложением [115]. Ключевую роль в экономике 
играют процессы, которые должны покупать процессорное время для выполнения 
своей работы, и узлы, продающие свои циклы процессоров на аукционе тому, кто 
предложит наивысшую цену. 

Каждый узел рекламирует свою приблизительную цену, публикуя ее в файле, 
доступном для чтения всем процессам. Эта цена не является фиксированной, но 
она дает представление об уровне предоставляемых услуг (в действительности это 
цена, которую заплатил предыдущий покупатель). У разных узлов цены могут 
различаться в зависимости от их быстродействия, объема оперативной памяти, на¬ 
личия быстрого аппаратного обеспечения для обработки операций с плавающей 
точкой и других свойств. Могут публиковаться и такие характеристики, как 
ожидаемое время отклика. 

Когда процесс хочет запустить дочерний процесс, он ищет узел, предлагающий 
требующиеся ему в данный момент услуги. Затем он определяет набор узлов, 
услугами которых он может воспользоваться. Из этого набора процесс выбирает 
лучшего кандидата, где слово «лучший» может означать самого дешевого, быстро- 
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го или с наилучшим соотношением производительность/цена. Процесс формиру¬ 
ет заявку с предложением цены и посылает ее первому кандидату. Предлагаемая 
цена может быть выше или ниже объявленной цены. 

Процессоры собирают все заявки, посланные им, и делают свой выбор, как пра¬ 
вило, останавливаясь на заявке с самой высокой ценой. Победители и проиграв¬ 
шие информируются о сделанном выборе. Победивший процесс исполняется. За¬ 
тем обновляется опубликованная цена сервера. 

Хотя авторы указанной выше статьи не вдаются в подробности, подобная эко¬ 
номическая модель поднимает ряд интересных вопросов, например: где процессы 
берут деньги на покупку услуг? Регулярно ли им выплачивают зарплату? По¬ 
лучают ли они одинаковые деньги, или деканы получают больше профессоров, 
а студенты, как всегда, получают меньше всех? Если в систему поступают новые 
пользователи, а количество ресурсов не увеличивается, вызывает ли это рост цен 
(инфляцию)? Могут ли узлы объединяться в картели для вздутия цен? Разреше¬ 
ны ли объединения пользователей в союзы? Вводится ли плата за дисковое про¬ 
странство и печать на принтере? Стоит ли печать изображений больше, чем пе¬ 
чать текста? Этот список вопросов можно продолжить. 


Распределенные системы 

Мы завершили наше знакомство с мультипроцессорами и многомашинными си¬ 
стемами. Теперь настала пора обсудить третий тип многопроцессорных систем: 
распределенные системы. Эта система сходна с многомашинной системой в том, 
что в такой системе нет общей физической памяти, а у каждого узла есть своя па¬ 
мять. Но в отличие от многомашинной системы, узлы распределенной системы 
связаны друг с другом не столь жестко. 

Во-первых, узел многомашинной системы, как правило, содержит центральный 
процессор, оперативную память, сетевую интерфейсную плату и, возможно, жест¬ 
кий диск для выгрузки страниц памяти. В отличие от него, узел распределенной 
системы представляет собой полноценный компьютер, с полным набором пери¬ 
ферийных устройств. Во-вторых, узлы многомашинной системы обычно распола¬ 
гаются в одном помещении, что позволяет соединить их высокоскоростной сетью, 
тогда как узлы распределенной системы могут быть распределены по всему миру. 
Наконец, все узлы многомашинной системы работают под управлением одной опе¬ 
рационной системы, совместно используют единую файловую систему и находят¬ 
ся под общим административным управлением. На узлах же распределенной 
системы могут работать различные операционные системы, у каждого узла своя 
файловая система, и администрация различных компьютеров также может быть 
разной. Типичный пример многомашинной системы — это 512 узлов в одной ком¬ 
нате в компании или университете, занимающихся, скажем, фармацевтическим 
моделированием, тогда как типичный пример распределенной системы состоит из 
тысяч машин, общающихся по Интернету. В табл. 8.1 сравниваются мультипро¬ 
цессоры, многомашинные системы и распределенные системы. 
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Таблица 8.1 . Сравнение трех типов многопроцессорных систем 

Аспект 

Мультипроцессор 

Многомашинная 

система 

Распределенная 

система 

Конфигурация узла 

Центральный 

процессор 

Центральный процессор, 
ОЗУ, сетевой интерфейс 

Полный компьютер 

Периферия узла 

Все общее 

Общая, кроме, 
может быть, дисков 

Полный набор 
для каждого узла 

Расположение 

В одном блоке 

В одном помещении 

Возможно, 
по всему миру 

Связь между узлами 

Общая память 

Выделенные линии 

Традиционная сеть 

Операционные 

системы 

Одна, общая 

Несколько, одинаковые 

Могут быть 
различными 

Файловые системы 

Одна, общая 

Одна, общая 

У каждого узла своя 

Администрирование 

Одна организация 

Одна организация 

Много организаций 


Многомашинные системы занимают в данной таблице середину. Возникает 
интересный вопрос: «К чему ближе многомашинные системы, к мультипроцессо¬ 
рам или к распределенным системам?» Как ни странно это может показаться, но 
ответ зависит от вашей точки зрения. С технической точки зрения у мультипроцес¬ 
соров есть общая память, которой нет у остальных двух видов многопроцессорных 
систем. Результатом этого отличия является использование различных программ¬ 
ных моделей. Однако с прикладной точки зрения мультипроцессоры и многома¬ 
шинные системы представляют собой просто несколько больших шкафов с аппа¬ 
ратурой, расположенных в одном помещении. И та и другая система используются 
для решения задач, требующих больших объемов вычислений, тогда как распре¬ 
деленная система, соединяющая компьютеры по Интернету, в большей степени 
занимается связью, чем вычислениями, и используется иначе. 

Слабое соединение компьютеров в распределенной системе одновременно яв¬ 
ляется и их силой, и узким местом. Сильная сторона заключается в том, что ком¬ 
пьютеры могут использоваться для широкого спектра приложений. Слабость со¬ 
стоит в том, что программирование таких приложений затрудняется отсутствием 
лежащей в основе общей модели. 

К типичным Интернет-приложениям относятся доступ к удаленному компью¬ 
теру (при помощи программ Іеіпеі и гІо@іп), доступ к удаленной информации (с по¬ 
мощью Всемирной паутины и протокола РТР), средства связи (электронная почта 
и чат) и многочисленные новые приложения (электронная коммерция, телемеди¬ 
цина и дистанционное обучение). Недостаток всех этих приложений состоит в том, 
что для каждого из них приходится изобретать колесо. Например, электронная 
почта, РТР и Всемирная паутина в основном занимаются перемещением файлов 
из пункта А в пункт В, но каждое из этих приложений делает это по-своему, ис¬ 
пользуя свои соглашения об именах, свои протоколы передачи, технику копиро¬ 
вания и т. д. Хотя многие ^еЬ-браузеры скрывают эти различия от пользователей, 
лежащие в основе приложений механизмы совершенно различны. Сокрытие раз¬ 
личий на уровне интерфейса пользователя подобно тому, как если бы кто-либо 
купил билет из Нью-Йорка в Сан-Франциско и только позднее обнаружил бы, был 
ли это билет на самолет, поезд или автобус. 
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Распределенная система добавляет к лежащей в основе сети некую общую па¬ 
радигму (модель), обеспечивающую однородный вид всей системы. Цель распре¬ 
деленной системы состоит в том, чтобы превратить множество слабосвязанных 
машин в когерентную систему, основанную на единой концепции. Иногда пара¬ 
дигма является простой, а иногда более сложной, но идея всегда заключается в том, 
чтобы предоставить нечто, объединяющее систему. 

Простой пример объединяющей парадигмы в слегка ином контексте можно 
обнаружить в системе ИШХ, в которой все устройства ввода-вывода выглядят как 
файлы. Возможность управлять всеми клавиатурами, принтерами и линиями по¬ 
следовательной передачи одним и тем же способом упрощает взаимодействие 
с этими устройствами. 

Один из способов, с помощью которого распределенная система может достичь 
определенного уровня однородности, несмотря на разницу в лежащем в основе 
аппаратном обеспечении, заключается в установке специального уровня программ¬ 
ного обеспечения поверх операционной системы. Этот уровень, называемый про¬ 
межуточным программным обеспечением, а также связующим или посредничес¬ 
ким программным обеспечением (тійсііе^аге), проиллюстрирован на рис. 8.27. 
Уровень предоставляет определенные структуры данных и операции, позволяю¬ 
щие процессам и пользователям на сильно удаленных машинах взаимодействовать 
друг с другом. 


Общая основа для приложений 
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Рис. 8.27. Положение промежуточного программного 
обеспечения в распределенной системе 


В определенном смысле промежуточное программное обеспечение подобно 
операционной системе распределенной системы. С другой стороны, оно не явля¬ 
ется операционной системой, поэтому мы не станем углубляться в детали в дан¬ 
ной книге. Подробнее о распределенных системах можно прочитать в [325]. В ос¬ 
тавшейся части этой главы мы кратко познакомимся с аппаратным обеспечением 
распределенных систем (то есть с лежащей в их основе компьютерной сетью), 
а затем с программным обеспечением связи (сетевыми протоколами). После этого 
мы рассмотрим несколько парадигм, используемых в данных системах. 
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Сетевое аппаратное обеспечение 

Распределенные системы создаются поверх компьютерных сетей, поэтому следу¬ 
ет привести краткое введение в данный предмет. Существует два основных типа 
сетей: локальные сети (ЬАМ, Ьосаі Агеа Кеілѵогк), покрывающие одно здание или 
территорию учреждения, и глобальные сети (\ѴАЫ, ЛѴісіе Агеа Кеі\ѵогк), которые 
могут охватывать целый город, страну или даже весь мир. Наиболее важной 
разновидностью локальной сети является сеть ЕіЬегпеІ, поэтому мы рассмотрим 
ее в качестве примера локальной сети. Глобальные сети мы рассмотрим на приме¬ 
ре сети Интернет, хотя технически Интернет представляет собой не единую сеть, 
а федерацию тысяч отдельных сетей. Однако в нашем случае можно рассматри¬ 
вать ее как единую глобальную сеть. 


ЕШегпеі 

Классическая сеть ЕіЬегпеІ, описанная в стандарте ІЕЕЕ 5іап<іаг<і 802.3, состоит 
из коаксиального кабеля, к которому присоединены несколько компьютеров. Кабель 
называется ЕіЬегпеІ в честь светоносного эфира, по которому, как когда-то полага¬ 
ли, распространяются электромагнитные волны. (Когда английский физик девят¬ 
надцатого столетия Джеймс Кларк Максвелл обнаружил, что электромагнитное 
излучение может быть описано волновым уравнением, ученые предположили, что 
пространство должно быть заполнено неким эфирным носителем, колебаниями 
которого являются электромагнитные волны. Только после знаменитого экспери¬ 
мента Михельсона и Морли в 1887 году, которым не удалось обнаружить эфир, 
физики поняли, что радиация может распространяться в вакууме.) 

В первой версии сети ЕіЬегпеІ компьютер присоединялся к кабелю при помо¬ 
щи ответвителя, называемого «зубом вампира», который буквально протыкал ка¬ 
бель иглой до середины. Схема сети ЕіЬегпеІ показана на рис. 8.28, а. Этим зубом 
было трудно попасть в жилу, поэтому ранее использовались настоящие соедини¬ 
тели. Тем не менее электрически все компьютеры были соединены так, как если 
бы кабели их сетевых интерфейсных карт были спаяны вместе. 


Компьютер^ 


т т ? ? ? 


\ 


ЕІЬѳгпѳІ 



Рис. 8.28. Классическая сеть ЕіЬѳгпѳі (а); коммутируемая сеть ЕШегпеі (б) 


Чтобы послать пакет по сети ЕіЬегпеІ, компьютер сначала прослушивает кабель, 
определяя, не передает ли по нему какой-либо другой компьютер. Если кабель сво¬ 
боден, он начинает передавать пакет, состоящий из короткого заголовка, за которым 
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следует от 0 до 1500 байт полезной нагрузки. Если кабель занят, компьютер про¬ 
сто ждет, пока не завершится текущая передача, после чего начинает передавать сам. 

Если два компьютера начинают передачу одновременно, происходит конфликт, 
который обнаруживается обоими компьютерами. При этом оба компьютера пре¬ 
кращают передачу и ожидают в течение случайного интервала времени от 0 до 
Т мкс, после чего начинают все сначала. Если опять происходит столкновение па¬ 
кетов, компьютеры ждут в течение случайного интервала времени от 0 до 2 Т мкс 
и т. д. При каждом следующем столкновении максимальный интервал ожидания 
удваивается, в результате чего вероятность следующего столкновения снижается. 
Такой алгоритм называется двоичным экспоненциальным откатом. Мы уже встре¬ 
чались с ним, когда рассматривали способы снижения накладных расходов при 
опросе мьютексов. 

Длина кабеля и число компьютеров в сети ЕіЬегнеІ ограничены. Чтобы выйти 
за допустимые стандартом пределы, можно объединить несколько сетей ЕіЬегпеІ 
при помощи устройств, называемых мостами. Мост позволяет трафику перете¬ 
кать из одной сети в другую, обеспечивая общение компьютеров, находящихся 
в разных сетях. 

Во избежание проблем со столкновениями пакетов в современных сетях ЕіЬегпеІ 
применяются коммутаторы (рис. 8.28, б). У каждого коммутатора есть несколько 
портов, к которым можно присоединить компьютер, сеть ЕіЬегпеІ или другой ком¬ 
мутатор. Если пакету удается избежать столкновений и добраться до коммутато¬ 
ра, он там буферируется и пересылается через порт в направлении машины-полу¬ 
чателя. Если каждому компьютеру выделить собственный отдельный порт, можно 
устранить все столкновения пакетов. Платой за это будут более громоздкие и до¬ 
рогие коммутаторы. Возможны компромиссные решения, при которых к одному 
порту подключаются несколько компьютеров. 

Интернет 

Сеть Интернет появилась как развитие экспериментальной сети с коммутацией 
пакетов АКРАИЕТ, финансируемой управлением перспективного планирования 
научно-исследовательских работ (АКРА, Асіѵапсесі КезеагсЬ Ргс^есСз Агенсу) при 
Министерстве обороны США. Ее жизнь началась в декабре 1969 года с трех компь¬ 
ютеров в Калифорнии и одного в штате Юта. Цель данного проекта заключалась 
в создании высоконадежной сети, способной обеспечивать передачу военной 
информации даже в случае поражения большого числа отдельных участков сети 
в результате прямого попадания в них ядерных зарядов. При этом данная сеть долж¬ 
на была автоматически перенаправлять трафик в обход поврежденных узлов. 

В 70-е годы сеть АКРАИЕТ быстро росла и в конечном итоге соединила сотни 
компьютеров. Наконец, к ней были присоединены радиосеть, спутниковая сеть и 
тысячи сетей ЕіЬегпеІ, в результате чего была сформирована федерация сетей, из¬ 
вестная сегодня как Интернет. 

Интернет состоит из компьютеров двух типов: хостов и маршрутизаторов. 
Хостами являются персональные компьютеры, лэптопы, палмтопы, серверы, 
мэйнфреймы и другие компьютеры, являющиеся собственностью компаний и част¬ 
ных лиц, желающих подключиться к Интернету. Маршрутизаторы — это специа¬ 
лизированные коммутирующие компьютеры, принимающие приходящие пакеты 
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с одной или нескольких линий и отправляющие их дальше по одной или несколь¬ 
ким выходным линиям. Маршрутизатор подобен коммутатору (см. рис. 8.28, б), но 
также и отличается от него. Мы не станем обсуждать здесь отличия маршрутиза¬ 
тора от коммутатора. Маршрутизаторы объединяются в большие сети, в которых 
каждый маршрутизатор связан проводами или оптоволоконными кабелями с дру¬ 
гими маршрутизаторами и хостами. Большие национальные и глобальные сети 
маршрутизаторов управляются телефонными компаниями и поставщиками услуг 
Интернета. 

На рис. 8.29 показана схема части Интернета. Наверху мы имеем магистрали, как 
правило, управляемые магистральным оператором. Магистраль состоит из не¬ 
которого количества соединенных высокоскоростными оптоволоконными кабеля¬ 
ми маршрутизаторов, связанных также с магистралями, управляемыми другими 
(конкурирующими) телефонными компаниями. Хосты, как правило, не присо¬ 
единяются напрямую к магистралям, если не считать необходимые для управления 
и тестирования магистрали машины, управляемые телефонными компаниями. 



Рис. 8.29. Часть Интернета 


К магистральным маршрутизаторам с помощью среднескоростных оптоволокон¬ 
ных кабелей присоединяются региональные сети и маршрутизаторы поставщиков 
услуг Интернета. К маршрутизаторам региональных сетей подключаются маршру¬ 
тизаторы корпоративных локальных сетей ЕсЬегпеС. Маршрутизаторы поставщиков 
услуг Интернета соединяются с модемными блоками, которыми пользуются кли¬ 
енты Интернет-провайдеров. Таким образом, у каждого хоста в Интернете есть как 
минимум один путь, а часто много путей ко всем остальным хостам. 

Весь трафик в Интернете посылается в виде пакетов. Каждый пакет содержит 
адрес пункта назначения, который используется при выборе маршрута. Когда пакет 
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попадает на маршрутизатор, маршрутизатор извлекает из него адрес получателя и 
ищет (часть) его в таблице, определяя, по какой выходной линии отправить этот 
пакет дальше следующему маршрутизатору. Эта процедура повторяется до тех пор, 
пока пакет не достигнет хоста-адресата. Таблицы маршрутизации в большой сте¬ 
пени динамичны и постоянно обновляются по мере того, как маршрутизаторы и 
линии связи отключаются и снова включаются, а также при изменении состояния 
трафика. 

Сетевые службы и протоколы 

Все компьютерные сети предоставляют своим пользователям (хостам и процес¬ 
сам) определенные службы, реализуемые с помощью установленных правил, опи¬ 
сывающих обмен сообщения. Ниже мы кратко рассмотрим эти темы. 

Сетевые службы 

Компьютерные сети предоставляют хостам и процессам, пользующимся ими, служ¬ 
бы двух типов: ориентированные на соединение и без установления соединения. 
Модель ориентированной на соединение службы действует подобно телефонной 
системе. Чтобы поговорить с кем-нибудь, нужно поднять трубку, набрать номер, 
поговорить, после чего повесить трубку. Точно так же при пользовании службой 
на основе соединений сначала устанавливается соединение, используется, после 
чего служба разрывает связь. Существенным моментом подобного соединения 
является то, что оно действует подобно трубе: отправитель посылает объекты (биты) 
с одного конца, а получатель извлекает их на другом конце в том же самом порядке. 

Службы без установления соединения, напротив, являются моделью почто¬ 
вой системы. Каждое сообщение (письмо) содержит полный адрес назначения, 
и каждое сообщение пересылается по системе независимо от остальных. Обычно 
сообщение, отправленное первым, будет первым и получено. Однако в данной 
модели это не всегда так. Первое сообщение может по какой-либо причине задер¬ 
жаться в пути и прийти вторым. В модели служб на основе соединений подобное 
нарушение порядка невозможно. 

Каждая служба характеризуется качеством обслуживания. Некоторые служ¬ 
бы являются надежными в том смысле, что они никогда не теряют данные. Обыч¬ 
но надежная служба реализуется при помощи подтверждений, посылаемых полу¬ 
чателем в ответ на каждое принятое сообщение, так что отправитель знает, дошло 
ли очередное сообщение или нет. Процесс пересылки подтверждений требует не¬ 
которых накладных расходов и снижает пропускную способность канала. Обычно 
подобные затраты не очень велики и окупаются, хотя иногда могут быть нежела¬ 
тельными. 

Типичным примером необходимости надежной службы на основе соединений 
является пересылка файлов. Владелец файла хочет быть уверен, что все биты фай¬ 
ла прибыли без искажений и в том же порядке, в котором были отправлены. Вряд 
ли кто отдаст предпочтение службе, которая случайным образом искажает инфор¬ 
мацию, даже если она значительно быстрее. 
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Надежные службы на основе соединений бывают двух типов: последователь¬ 
ности сообщений и байтовые потоки. В первом варианте сохраняются границы 
между сообщениями. Когда посылаются два сообщения размером по 1 Кбайт, то 
они прибывают в виде двух сообщений размером по 1 Кбайт и никогда как одно 
двухкилобайтное сообщение. При втором варианте связь представляет собой про¬ 
сто поток байтов, без разделения на отдельные сообщения. Когда 2 Кбайт прибы¬ 
вает к получателю, то нет способа определить, было ли это одно сообщение дли¬ 
ной 2 Кбайт, два сообщения длиной 1 Кбайт или же 2048 однобайтных сообщений. 
Если страницы книги посылаются по сети фотонаборной машине в виде отдель¬ 
ных сообщений, то, возможно, необходимо сохранить границы между сообщения¬ 
ми. С другой стороны, при регистрации с удаленного терминала в системе разде¬ 
ления времени вполне достаточно потока байтов с терминального компьютера. 

Существуют системы, для которых задержки, связанные с пересылкой под¬ 
тверждений, неприемлемы. В качестве примера такой системы можно назвать циф¬ 
ровую голосовую связь. В данном случае предпочтительнее допустить шумы на 
линии или искаженные слова, нежели большие паузы, вызванные отсылкой под¬ 
тверждений и повторной передачей блоков данных. 

Не все приложения требуют установки соединения. Например, при тестирова¬ 
нии сети все, что требуется, — это способ переслать сообщение с высокой вероят¬ 
ностью его получения, но без гарантии. Ненадежная (то есть без подтверждений) 
служба без установления соединения часто называется службой дейтаграмм или 
дейтаграммной службой, по аналогии с телеграфной службой, также не предостав¬ 
ляющей подтверждений отправителю. 

В других ситуациях бывает желательно отсутствие установления соединения 
для пересылки коротких сообщений, но надежность тем не менее существенна. 
Такая служба называется службой дейтаграмм с подтверждениями. Она подобна 
отправке заказного письма с подтверждением получения. Получив подтверждение, 
отправитель уверен, что письмо доставлено адресату, а не потеряно по дороге. 

Кроме того, существует служба запросов и ответов, в которой отправитель 
посылает дейтаграммы, содержащие запросы, и получает ответы от получателя. 
Например, к данной категории можно отнести запрос к локальной библиотеке о том, 
где говорят по-уйгурски. Обычно модель запросов и ответов применяется для реа¬ 
лизации общения в модели клиент-сервер: клиент посылает запрос, а сервер отве¬ 
чает на него. Обсуждавшиеся выше типы служб сведены в таблицу на рис. 8.30. 


Ориентированный 
на соединение 


Без установления 
соединения 


Служба 

Пример 

Надежный поток сообщений 

Последовательность страниц 

Надежный поток байт 

Удаленная регистрация 

Ненадежное соединение 

Цифровая голосовая связь 

Ненадежная дейтаграмма 


Дейтаграмма с подтверждением 

Заказные письма 

Запрос-ответ 

Запрос к базе данных 


Рис. 8.30. Шесть типов служб 
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Сетевые протоколы 

Во всех сетях есть узкоспециализированные правила, описывающие типы и фор¬ 
маты сообщений, которые могут посылаться в этих сетях, а также регламентирую¬ 
щие ответы на эти сообщения. Например, при некоторых обстоятельствах (скажем, 
перенос файла), когда сообщение посылается от источника адресату, адресат дол¬ 
жен послать в ответ подтверждение правильного приема сообщения. В другой си¬ 
туации (например, при цифровой телефонии) подтверждения в ответ отправлять 
не требуется. Набор правил, с помощью которых общаются компьютеры, назы¬ 
вается протоколом. Существует множество протоколов, включая протоколы для 
общения маршрутизатора с маршрутизатором, хоста с хостом и т. д. Детальный 
обзор компьютерных сетей и их протоколов см. в [323]. 

Все современные сети используют то, что называется стеком протоколов, то 
есть разные протоколы на разных уровнях. На разных уровнях протоколы зани¬ 
маются различными вопросами. Так, на нижнем уровне протоколы описывают, как 
определить, где в битовом потоке начинается и заканчивается пакет данных. На 
более высоком уровне протоколы занимаются выбором маршрута пакета по слож¬ 
ным сетям от отправителя до получателя. А на еще более высоком уровне они га¬ 
рантируют, что все пакеты сообщения прибыли правильно и в нужном порядке. 

Так как большинство распределенных систем используют в качестве основы 
Интернет, ключевыми протоколами этих систем являются два главных протокола 
Интернета: ІР и ТСР. Протокол ІР (Іпіегпеі Ргоіосоі — Интернет-протокол) пред¬ 
ставляет собой дейтаграммный протокол, в котором отправитель вбрасывает в сеть 
дейтаграмму размером до 64 Кбайт и надеется, что она достигнет получателя. 
Никаких гарантий не предоставляется. Дейтаграмма может фрагментироваться по 
пути на пакеты меньшего размера. Эти пакеты перемещаются по Интернету неза¬ 
висимо друг от друга, возможно, по разным маршрутам. Когда все пакеты достига¬ 
ют адресата, они собираются в нужном порядке и доставляются получателю. 

В настоящий момент применяются две версии протокола ІР: ѵ 4 и ѵ 6. На сегод¬ 
ня доминирует 4-я версия, поэтому мы опишем в данной книге ее, однако версия ѵб 
получает все большую популярность. Каждый пакет протокола ІР ѵ 4 начинается 
с 40-байтового заголовка, содержащего, помимо других полей, 32-разрядный 
адрес отправителя и 32-разрядный адрес получателя. Эти адреса, называемые 
ІР-адресами, образуют основу маршрутизации в Интернете. Как правило, они 
записываются четырьмя десятичными числами от 0 до 255, разделенными точка¬ 
ми, например 192.31.231.65. Когда пакет прибывает на маршрутизатор, маршрути¬ 
затор извлекает из него адрес получателя и использует его для маршрутизации 
пакета. 

Поскольку получение ІР-дейтаграмм не подтверждается, для надежной связи 
в Интернете одного протокола ІР недостаточно. Надежную связь обеспечивает 
другой протокол, обычно устанавливаемый поверх протокола ІР. Это протокол 
ТСР (Тгапзтіззіоп Сопігоі Ргоіосоі — протокол управления передачей). Протокол 
ТСР использует протокол ІР для обеспечения ориентированных на соединение 
потоков. Чтобы воспользоваться протоколом ТСР, процесс сначала устанавлива¬ 
ет соединение с удаленным процессом. Требуемый процесс обозначается ІР-адре- 
сом машины и номером порта на этой машине, который прослушивают процессы, 
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заинтересованные в получении входящего соединения. Когда соединение уста¬ 
новлено, процесс просто передает по нему байты, которые гарантированно вы¬ 
ходят с другого конца соединения неповрежденными и в правильном порядке. Реа¬ 
лизация протокола ТСР добивается этого при помощи порядковой нумерации, 
контрольных сумм и повторной передачи неверно полученных пакетов. Все это 
прозрачно для отправляющего и для получающего процессов. Они просто видят 
надежную межпроцессную связь, подобную каналу в системе ИЫІХ. 

Чтобы понять, как взаимодействуют данные протоколы, рассмотрим простей¬ 
ший случай пересылки очень маленького сообщения, для которого не требуется 
фрагментация ни на одном уровне. Хост находится в сети ЕіЬегпеІ, соединенной 
с Интернетом. Что происходит? Пользовательский процесс формирует сообщение 
и обращается к системному вызову, чтобы послать это сообщение по заранее ус¬ 
тановленному ТСР-соединению. Стек протоколов ядра добавляет к началу сооб¬ 
щения ТСР-заголовок, а затем ІР-заголовок. Потом сообщение поступает к драй¬ 
веру сети ЕіЬегпеІ, который добавляет свой заголовок, направляя, таким образом, 
пакет к маршрутизатору в сети ЕгЬеппЧ. Этот маршрутизатор посылает пакет по 
Интернету, как показано на рис. 8.31, 


Интернет 



Для установки соединения с удаленным хостом (даже чтобы просто послать 
дейтаграмму) необходимо знать его ІР-адрес. Так как пользоваться списками 
32-разрядных ІР-адресов неудобно для людей, была разработана схема, называ¬ 
емая □N5 (Иошаіп Ыаше Зузіеш — служба имен доменов). Она представляет 
собой базу данных, преобразующую имена хостов в формате А5СІІ в их ІР-адре- 
са. Данная система позволяет использовать ИИЗ-имя зіаг.сз.ѵи.пі вместо соответ¬ 
ствующего ему ІР-адреса 130.37.24.6. ИЫ5-имена получили большую популяр¬ 
ность благодаря электронной почте Интернета, в которой адреса имели форму 
и5ег-пате@0М5-Но5І:-пате. При такой системе имен почтовая программа на пере¬ 
дающем хосте ищет ІР-адрес хоста-получателя в базе данных ИИ5, устанавливает 
ТСР-соединение с почтовым демоном на этой машине и посылает сообщение в виде 
файла. Имя пользователя изег-пате отправляется вместе с письмом, чтобы указать, 
в какой почтовый ящик должно быть помещено письмо. 
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Промежуточное программное обеспечение, 
основанное на документе 

Теперь, познакомившись с сетями и протоколами, мы можем начать поиск различ¬ 
ных уровней промежуточного программного обеспечения, способных форми¬ 
ровать непротиворечивую парадигму для приложений и пользователей. Начнем 
с простого и хорошо всем известного примера: Всемирной паутины (\Ѵ\Ѵ\Ѵ, \ѴогЫ 
\Уійе \ѴеЬ). Паутина была изобретена Тимом Бернерсом-Ли в 1989 году в Евро¬ 
пейском центре ядерных исследований СЕНЫ (Сопзеіі Еигорееп роиг Іа КесЬегсЬе 
Иисіеаіге) в Швейцарии. С тех пор это приложение распространилось по всему 
миру со скоростью лесного пожара. 

Оригинальная парадигма приложения Всемирная паутина довольно проста: 
каждый компьютер может содержать один или несколько документов, называе¬ 
мых лѵеЬ-страницами. Каждая \ѵеЬ-страница может содержать текст, изображения, 
звук, видео и т. д„ а также гиперссылки (указатели) на другие \ѵеЬ-страницы. Ког¬ 
да пользователь запрашивает \ѵеЬ-страницу с помощью программы, называемой 
\ѵеЬ-браузером, страница отображается на экране. Щелчок мышью на ссылке вы¬ 
зывает замещение текущей страницы на экране страницей, на которую указывает 
ссылка. Хотя в последнее время во Всемирную паутину было имплантировано 
множество всяческих погремушек, лежащая в основе парадигма остается неизмен¬ 
ной: Паутина представляет собой большой направленный граф документов, кото¬ 
рые могут содержать ссылки на другие документы (рис. 8.32). 



Рис. 8.32. Паутина представляет собой направленный граф документов 


У каждой \ѵеЬ-страницы есть уникальный адрес, называемый ІШЬ (ЕГпііЪгт 
Везом гее Еосаіог — унифицированный указатель информационного ресурса), сле¬ 
дующего вида: протокол://ОЫ5-имя/имя _файла. Чаше всего применяется протокол 
Нйр (НурегТехІ Тгапзіег Ргоіосоі — протокол передачи гипертекстовых файлов), 
но существуют также и другие протоколы, например, /ф. Следом за протоколом 
указывается ОЫ5-имя хоста, содержащего файл. Наконец, указывается локальное 
имя файла, содержащего \ѵеЬ-страницу. 

В целом система работает следующим образом. Паутина представляет собой 
систему типа клиент-сервер, в которой пользователь является клиентом, а \ѵеЪ- 
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сайт — сервером. Когда пользователь предоставляет браузеру 1ШБ, либо вводя его 
в окне, либо щелкая мышью на гиперссылке в текущей странице, браузер предпри¬ 
нимает определенные действия, чтобы достать запрашиваемую страницу. Напри¬ 
мер, пусть, запрашиваемый ШІ [.-указатель представляет собой Нйр://ѵѵѵѵѵѵ.асш.огд/ 
ФДад.ЫтІ. Чтобы получить эту страницу, браузер выполняет следующие действия: 

1. Браузер запрашивает у ОИ5 ІР-адрес ѵѵѵѵѵѵ.асш.огд. 

2. ОЫ5 отвечает: 199.222.69.151.- 

3. Браузер устанавливает ТСР-соединение с портом 80 на хосте 199.222.69.151. 

4. Затем браузер запрашивает файл (ЛДад.ІіітІ. 

5. Сервер ѵѵѵѵѵѵ.асш.огд посылает файл (ЛДад.ІіІтІ. 

6. ТСР-соединение разрывается. 

7. Браузер отображает на экране текст (ЛДад.ЫтІ. 

8. Браузер получает по сети и отображает на экране все изображения (ЛДад.ЫтІ. 

В первом приближении такова основа Паутины. За десять с лишним лет ее 

существования были добавлены различные другие свойства, включая страницы 
стилей, динамические \уеЬ-страницы, формируемые на лету, \ѵеЬ-страницы, со¬ 
держащие небольшие программы или сценарии, исполняющиеся на клиентской 
машине и т. д., но все это выходит за рамки данного обсуждения. 

Промежуточное программное обеспечение, 
основанное на файловой системе 

Основная идея Всемирной паутины заключается в том, что распределенная систе¬ 
ма должна выглядеть как гигантская коллекция документов, связанных гипер¬ 
ссылками. Второй подход состоит в том, чтобы придать распределенной системе 
вид огромной файловой системы. В данном разделе мы рассмотрим некоторые 
вопросы разработки всемирной файловой системы. 

Использование модели файловой системы для распределенной системы озна¬ 
чает, что имеется единая глобальная файловая система с пользователями по все¬ 
му миру, способными читать и писать файлы, к которым у них есть доступ. Для 
связи процессов используется файловый обмен. Один процесс записывает данные 
в файл, а другой процесс считывает их оттуда. При таком подходе возникает мно¬ 
жество стандартных вопросов, связанных с файловой системой, но также появля¬ 
ются и новые вопросы, относящиеся к распределению. 

Модель переноса 

Первый вопрос заключается в выборе между моделью закачивания/скачивания 
и моделью удаленного доступа. В первой модели, показанной на рис. 8.33, а, чтобы 
получить доступ к файлу, процесс сначала считывает его с удаленного сервера, на 
котором хранится этот файл. Если для файла разрешено только чтение, то файл 
читается локально для более высокой производительности. Если файл должен 
быть записан, он записывается также локально. Когда процесс заканчивает работу 
с файлом, обновленный файл отправляется обратно на сервер. В модели удален- 
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ного доступа файл остается на сервере, а клиент посылает серверу команды для 
выполнения работы на месте (рис. 8.33, б). 


1. Клиент получает файл 



Старый файл 
Новый файл 


2. Доступ к файлу 3 - Когда клиент завершает работу, 
осуществляется файл возвращается на сервер 
на клиентской машине 


Клиент 


Запрос 

Ответ 


Сервер 


ЕЕ 

11 




Файл остается 
на сервере 


Рис. 8.33. Модель закачивания/скачивания (а); коммутируемая сеть ЕФегпеІ (б) 


Преимущество модели закачивания/скачивания заключается в ее простоте 
и том факте, что перенос файла целиком эффективнее, чем перенос его по частям. 
К недостаткам данной модели относится необходимость наличия достаточно боль¬ 
шого объема памяти для хранения файла целиком локально, к тому же перенос 
файла целиком, когда требуется только его часть, представляет собой излишние 
расходы. Наконец, при наличии нескольких конкурирующих пользователей воз¬ 
никает проблема непротиворечивости файлов. 


Иерархия каталогов 

Файлы представляют собой только часть этой картины. Другой ее частью являет¬ 
ся система каталогов. Все распределенные файловые системы поддерживают ка¬ 
талоги, содержащие многочисленные файлы. Следующий вопрос проектирования 
заключается в том, одинаково ли выглядит иерархия каталогов для всех клиен¬ 
тов. Поясним смысл этого вопроса с помощью рис. 8.34. Квадратами на рисунке 
изображены каталоги, а кружочками — файлы. На рис. 8.34, а показаны два фай¬ 
ловых сервера, каждый из которых содержит три каталога и несколько файлов. 
На рис. 8.34, б мы видим систему, в которой для всех клиентов (и других машин) 
распределенная файловая система выглядит одинаково. Если путь /Б/Е/х есть на 
одной машине, то он есть и на другой. 

На рис. 8.34, в, напротив, разные машины видят файловую систему по-разно¬ 
му. Путь /О /Е/х может существовать на клиенте 1, но отсутствовать на клиенте 2. 
Для систем, работающих с удаленными серверами при помощи удаленного мон¬ 
тирования, ситуация на рис. 8.34, в является нормой. Такая схема обладает гиб¬ 
костью и простотой реализации. Недостаток этого подхода заключается в том, 
что он не обеспечивает поведения всей системы как единой старомодной системы 
разделения времени. В системе разделения времени файловая система выглядит 
одинаково для всех процессов (рис. 8.34, б). Это облегчает программирование и ра¬ 
боту в системе. 

С этим вопросом близко связан такой вопрос, как наличие в системе глобаль¬ 
ного каталога, распознаваемого всеми машинами как корневого. Один из спосо¬ 
бов поддержки глобального корневого каталога состоит в том, чтобы создать кор¬ 
невой каталог, содержащий все серверы, и ничего, кроме серверов. При этом все 
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пути примут вид /сервер/путь. У такого подхода имеются свои недостатки, но, по 
меньшей мере, пути будут одинаковыми для всей системы. 


Файловый 

сервер 1 Клиент 1 Клиент 1 



Файловый 

сервер 2 ' Клиент 2 Клиент 2 



в 

Рис. 8.34. Два файловых сервера (а); система, в которой для всех клиентов файловая 
система выглядит одинаково (б); система, в которой разные машины видят файловую 

систему по-разному (в) 

Прозрачность именования 

Главная проблема такого способа именования заключается в том, что она не пол¬ 
ностью прозрачна. В данном контексте существует две формы прозрачности, ко¬ 
торые следует различать. Первая форма, называемая прозрачностью местополо¬ 
жения, означает, что по имени пути невозможно определить расположение файла. 
По пути вида /зегѵегі/еіігі/ сііг2/х всем сразу становится ясно, что файл х находится 
на сервере 5 егѵегі, но при этом остается неизвестным, где расположен сам сервер. 
Сервер может перемещаться по сети без необходимости изменения имени пути. 
Это означает, что система обладает прозрачностью местоположения. 
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Однако предположим, что файл х крайне велик, а на сервере 1 (зегѵегі) мало 
дискового пространства. Более того, предположим, что на сервере 2 свободного 
пространства много. Было бы разумно предусмотреть в такой ситуации возмож¬ 
ность автоматического перемещения файлах на сервер 2. К сожалению, когда имя 
сервера является первым компонентом всех путей, система не может переместить 
файл с одного сервера на другой, даже при наличии каталогов сіігі и сііг2 на обоих 
серверах. Проблема заключается в том, что при перемещении файла с сервера 1 на 
сервер 2 путь файла также изменится с /зегѵегі/сіігі /сііг2/х на /зетег2/ сіігі/Аіг2/х. 
Программы, обращающиеся к этому файлу по пути, не смогут более находить этот 
файл. Про системы, в которых файлы могут перемещаться с одного сервера на дру¬ 
гой без изменения пути файла, говорят, что они обладают независимостью от ме¬ 
стоположения. Распределенные системы, указывающие имя машины или 
сервера в пути файла, определенно не обладают данным свойством. Системы, ис¬ 
пользующие монтирование устройств, также не обладают независимостью от мес¬ 
тоположения, поскольку невозможно переместить файл из одной группы файлов 
(монтируемого модуля) в другую и продолжать при этом использовать старое имя 
пути. Независимость пути файла от его местоположения сложно реализовать, но 
это свойство представляет особую ценность для распределенных систем. 

Подытоживая вышесказанное, в распределенных системах можно отметить три 
общих подхода к именованию файлов и каталогов: 

1. Имя типа машина + файл, например, /машина/файл или машина:файл. 

2. Монтирование удаленной файловой системы в локальную файловую иерар¬ 
хическую структуру. 

3. Единое пространство имен, одинаково выглядящее на всех машинах. 

Первые два подхода легко реализуются, особенно как метод соединения суще¬ 
ствующих систем, при разработке которых не предполагалось их использование 
в качестве распределенных систем. Последний вариант сложен и требует деталь¬ 
ной проработки, но значительно облегчает жизнь программистам и пользователям. 

Семантика совместного использования файлов 

Когда два или более пользователей вместе используют один и тот же файл, необ¬ 
ходимо точно определить семантику чтения и записи файла, чтобы избежать воз¬ 
можных проблем. В однопроцессорных системах данные правила утверждают, что 
когда за системным вызовом мпѣе следует системный вызов геасі, то при чтении 
возвращается только что записанное значение (рис. 8.35, а). Аналогично, если 
системный вызов геасі следует за двумя последовательными системными вызова¬ 
ми мгііе, считывается значение, записанное последним системным вызовом мпЧе. 
Таким образом, все системные вызовы упорядочиваются системой в единую по¬ 
следовательность, одинаковую для всех процессов. Про такую модель говорят, что 
она обладает последовательной непротиворечивостью. 

В распределенной системе последовательная непротиворечивость может быть 
легко достигнута при условии, что имеется всего один файловый сервер, а клиен¬ 
ты не кэшируют файлы. Все системные вызовы геасі и мгіѣе поступают напрямую 
на файловый сервер, который обрабатывает их в строгой последовательности. 
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Клиент 1 



6 

Рис. 8.35. Последовательная непротиворечивость (а); в распределенной системе 
с кэшированием при чтении файла можно получить его устаревшую копию (б) 


Однако на практике производительность распределенной системы, в которой 
все файловые запросы должны выполняться на единственном сервере, как прави¬ 
ло, невысока. Эта проблема часто решается за счет разрешения клиентам содер¬ 
жать собственные локальные копии активно используемых файлов в своих част¬ 
ных кэшах. Однако если клиент 1 модифицирует файл локально, а вскоре после 
этого клиент 2 прочитает этот файл с сервера, у второго клиента окажется уста¬ 
ревшая копия файла (рис. 8.35, б). 

Один из способов разрешения данной проблемы заключается в том, чтобы не¬ 
медленно распространять все изменения кэшируемых файлов обратно на серве¬ 
ры. Альтернативное решение представляет собой ослабление семантики совмест¬ 
ного использования файлов. Вместо требования, чтобы при системном вызове геасі 
был виден эффект всех предшествовавших системных вызовов мгііе, новое пра¬ 
вило звучит так: «Изменения всех открытых файлов изначально видны только 
процессу, сделавшему эти изменения. Только когда файл закрывается, эти измене¬ 
ния становятся видны другим процессам». Принятие такого правила не изменит 
ситуацию на рис. 8.35, б , но благодаря ему такое поведение (процесс В получает 
оригинальную версию файла) будет теперь считаться правильным. Когда клиент 1 
закрывает файл, он посылает на сервер измененную копию файла, поэтому после- 
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дующие системные вызовы геасі, как и требовалось, получат новую копию. Практи¬ 
чески это все та же модель закачивания/скачивания, показанная на рис. 8.33. Данное 
семантическое правило широко применяется и называется сеансовой семантикой. 

Использование сеансовой семантики поднимает вопрос о том, что произойдет, 
если два или более клиентов одновременно прочитают в кэш и модифицируют 
один и тот же файл. Одно решение заключается в том, что по мере того, как эти 
клиенты станут поочередно закрывать файл, его модифицированная копия каж¬ 
дый раз будет посылаться на сервер. «Победит» тот клиент, который закроет файл 
последним. В качестве варианта такой семантики можно принять правило, соглас¬ 
но которому окончательный вариант будет выбираться из нескольких кандидатов 
неким неопределенным способом. 

Альтернативный подход к сеансовой семантике — использовать модель зака¬ 
чивания/скачивания, но автоматически блокировать скачанные файлы. Попытки 
всех остальных клиентов получить уже считанный кем-то файл будут приостанав¬ 
ливаться до того момента, пока первый клиент не вернет этот файл. Если данный 
файл пользуется повышенным спросом, сервер может посылать клиенту, удержи¬ 
вающему файл, сообщения с просьбой поторопиться, хотя клиент может и проиг¬ 
норировать данные просьбы. Итак, составление корректной семантики использо¬ 
вания общих файлов представляет собой непростое дело, в котором нет элегантных 
и эффективных решений. 

Файловая система АР5 

Некоторые системы промежуточного программного обеспечения, основанные на 
файловых системах, были построены и развернуты. Ниже мы кратко обсудим одну 
из таких систем, основанную на модели закачивания/скачивания (см. рис. 8.33, а). 
В главе 10 мы рассмотрим другую систему (ИР8), основанную на модели удален¬ 
ного доступа (см. рис. 8.33, б). 

Файловая система АР5 была разработана и реализована в университете Карне¬ 
ги—Меллона [158,239,292]. Эта система была названа Апс1ге\ѵ Рііе Зувіеш в честь 
двух первых спонсоров университета Эндрю Карнеги и Эндрю Меллона. Цель 
проекта, запущенного в начале 80-х годов, заключалась в обеспечении каждого 
студента и каждого сотрудника университета мощной рабочей станцией под управ¬ 
лением операционной системы ІЖІХ, но с общей файловой системой. В данном 
случае файловая система использовалась в качестве системы промежуточного про¬ 
граммного обеспечения, чтобы превратить множество рабочих станций в единую 
когерентную систему. 

У каждого пользователя файловой системы АР8 есть своя рабочая станция, на 
которой работает слегка модифицированная версия системы ІЖІХ. Модифика¬ 
ция заключается в добавлении к ядру программы, называемой ѵепиз (Венера), 
и запуске файлового сервера ѵісе (вице-сервера) в пространстве пользователя. 
(Изначально программа ѵепиз также работала в пользовательском пространстве, 
но затем она была перемещена в ядро по соображениям производительности.) 
Расположение программ ѵепиз и ѵісе показано на рис. 8.36, а. В административ¬ 
ных целях рабочие станции пользователей группируются в ячейки. Ячейкой 
может быть локальная сеть, множество объединенных локальных сетей или даже 
целый факультет. 
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Рис. 8.36. Расположение программ ѵепиз и ѵісе в файловой системе АРЗ (а); 
файловая система с точки зрения клиента (б) 


Видимое программам пользователя пространство имен выглядит как традици¬ 
онное дерево ІЖІХ с добавлением каталогов /сти и /саске (рис. 8.36, б). Каталог 
/саске содержит имена кэшированных удаленных файлов. Каталог /сти содержит 
имена удаленных совместно используемых ячеек, под которыми располагаются их 
файловые системы. В результате удаленные файловые системы монтируются 
в каталоге /сти. Остальные каталоги и файлы являются локальными и не исполь¬ 
зуются совместно. Разрешаются символьные ссылки от локальных файлов к со¬ 
вместно используемым файлам, как показано на примере файла зк на рис. 8.36, б. 

Основная идея файловой системы АР8 заключается в том, чтобы пользователь 
максимально применял потенциал локальной работы и, по возможности, мини¬ 
мально взаимодействовал с остальной частью системы. При открытии файла про¬ 
грамма ѵепиз перехватывает системный вызов ореп и загружает файл целиком (или 
если файл очень велик, то большую его часть) на локальный диск в каталог /саске. 
Дескриптор файла, возвращаемый системным вызовом ореп, ссылается на файл 
в каталоге /саске, так что последующие системные вызовы геасі и мгііе использу¬ 
ют этот кэшированный файл. 

Семантика, предлагаемая файловой системой АР8, близка к сеансовой семанти¬ 
ке. Когда файл открывается, он получается с соответствующего сервера и помеща¬ 
ется в каталог /саске на локальном диске рабочей станции. Все операции чтения 
и записи выполняются с этой кэшированной копией файла. Когда файл закрыва¬ 
ется, он закачивается обратно на сервер. 

Однако для предотвращения возможности использования несвежих копий 
файла другими процессами программа ѵепиз, загружая файл в кэш, сообщает про¬ 
грамме ѵісе, следует ли отслеживать последовательные обращения других процес¬ 
сов к этому файлу. Если да, то вице-сервер записывает расположение кэширован¬ 
ного файла. Когда другой процесс системы открывает этот же файл, программа ѵісе 
посылает программе ѵепиз соответствующее сообщение, после чего программа ѵепиз 
помечает элемент кэша как недействительный и, если копия файла была измене¬ 
на, она копируется обратно на сервер. 
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Промежуточное программное обеспечение, 
основанное на совместно используемых объектах 

Рассмотрим теперь третью парадигму. Вместо того чтобы считать все документа¬ 
ми или файлами, будем называть все, что есть в системе, объектами. Объект — это 
набор переменных, объединенных вместе с набором процедур доступа к ним, на¬ 
зываемых методами. Процессам не разрешается получать доступ к переменным 
напрямую. Вместо этого они должны вызывать методы. 

СОПВА 

Некоторые языки программирования, такие как С++ и }аѵа, являются объектно-ори¬ 
ентированными, но они имеют дело с объектами языкового уровня, а не с объекта¬ 
ми времени исполнения. Одной из популярных систем, основанных на объек¬ 
тах времени исполнения, является технология СОКВА (Соттоп ОІуесС КэдиезТ 
Вгокег Лгсііііесіиге — архитектура распределенных объектных приложений) [344]. 
Технология СОКВА представляет собой систему типа клиент-сервер, в которой 
клиентский процесс может осуществлять операции с объектами, расположенны¬ 
ми на серверах. Архитектура СОКВА была разработана для неоднородной систе¬ 
мы, состоящей из разнообразных аппаратных платформ и операционных систем, 
и программировалась на нескольких языках. Чтобы клиент на одной платформе 
мог вызвать сервер на другой платформе, между клиентом и сервером располага¬ 
ются специальные программные посредники, называемые ОКВ (ОІуесС КэдиезС 
Вгокег — брокер объектных запросов). Посредники ОКВ играют в архитектуре 
СОКВА важную роль. Благодаря им сама архитектура получила свое название. 

Каждый объект системы СОКВА описывается на специальном языке описания 
интерфейсов ГОЬ (ІпГегГасе ОеГіпіііоп Бап§иа§е). В определении объекта указы¬ 
ваются методы, экспортируемые объектом, и типы параметров для каждого мето¬ 
да. Спецификация ШБ может быть откомпилирована в клиентскую процедуру- 
заглушку и храниться в библиотеке. Если клиентскому процессу заранее известно, 
что ему потребуется доступ к определенному объекту, этот объект компонуется 
вместе с объектным кодом клиентской заглушки. Спецификация ШЕ также может 
быть откомпилирована вместе со скелетной процедурой, используемой на сервер¬ 
ной стороне. Если заранее нельзя сказать, какие объекты СОКВА понадобятся 
процессу, возможно также применение динамического вызова, но принципы рабо¬ 
ты этого метода выходят за пределы данной книги. 

При создании объекта СОКВА также создается ссылка на этот объект, которая 
возвращается процессу, создавшему объект. В дальнейшем процесс обращается к 
методам созданного объекта по этой ссылке. Ссылка может быть передана другим 
процессам или сохранена в объектной библиотеке. 

Чтобы вызвать метод объекта, клиентский процесс сначала должен получить 
ссылку на этот объект. Ссылку можно получить либо напрямую от создавшего 
объект процесса, либо при помощи поиска этого объекта или его метода по имени 
в специальном каталоге. Когда ссылка на объект получена, клиентский процесс 
упаковывает параметры вызываемого метода в стандартную структуру и связыва¬ 
ется с клиентским О КВ-посредником. Тот, в свою очередь, посылает сообщение 
серверному О КВ-посреднику, который вызывает метод объекта. Весь механизм 
схож с вызовом удаленной процедуры КРС. 
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Цель ОКВ-посредников заключается в сокрытии всех низкоуровневых деталей 
связи и распределения от клиентской и серверной программ. В частности, ОКВ- 
посредники скрывают от клиента расположение сервера, аппаратное обеспечение 
сервера и операционную систему, работающую на сервере, информацию о том, 
является ли сервер двоичной программой или сценарием, является ли объект 
активным в настоящий момент, а также способ общения двух ОКВ-посредников 
(ТСР/ІР, КРС, общая память и т. д.). 

В первой версии системы СОКВА протокол между клиентским и серверным 
ОКВ-посредниками не был определен. В результате каждый разработчик ОКВ- 
посредников использовал свой отличный протокол, и различные реализации ОКВ 
не могли общаться друг с другом. Протокол был определен в версии 2.0. Для связи 
через Интернет используется протокол, называемый НОР (ІпІегпеГ ІпІегОКВ 
Ргоіосоі — протокол для связи между ОКВ-посредниками по Интернету). 

Чтобы было можно использовать в системах СОКВА объекты, не предназна¬ 
ченные специально для этого, каждый объект оснащается адаптером объекта. Это 
упаковщик, обрабатывающий такие рутинные операции, как формирование ссы¬ 
лок на объект и активация объекта в случае, если при вызове тот находится в неак¬ 
тивном состоянии. Организация всех этих частей системы СОКВА показана на 
рис. 8.37. Детали системы СОКВА показаны серым цветом. 


Клиентская 

программа 


Клиентская заглушка 



\ 

Сеть 


Рис. 8.37. Основные элементы распределенной системы, основанной на архитектуре СОВВА 


Серьезный недостаток системы С О КВА заключается в том, что каждый объект 
расположен только на одном сервере, что означает крайне низкую производитель¬ 
ность для объектов, одновременно используемых многими клиентами. На практи¬ 
ке архитектура СОКВА может приемлемо работать только в небольших системах, 
например, соединять процессы на одном компьютере, в пределах одной локальной 
сети или одной компании. 


Система СІоЬе 

В качестве примера распределенной объектной системы, специально разработан¬ 
ной для поддержки миллиарда пользователей и триллиона объектов по всему 
миру, рассмотрим систему СІоЬе [340, 341]. Для создания очень больших систем 
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используются две ключевые идеи. Первая из них — реплицируемые объекты. Если 
имеется единственная копия популярного объекта, доступ к которому хотят полу¬ 
чить миллионы пользователей по всему миру, объект физически не сможет обра¬ 
ботать все запросы. Подумайте об объекте, занимающемся биржевыми сводками 
или результатами спортивных соревнований. Репликация объекта позволяет рас¬ 
пределить нагрузку по репликам. 

Вторая ключевая идея заключается в гибкости. Во всемирной системе с милли¬ 
ардом пользователей нет способа добиться всеобщего согласия по вопросу о выборе 
языка программирования, единой репликационной стратегии, общей модели без¬ 
опасности или еще по какому-либо вопросу. Система должна позволять различное 
поведение различных пользователей и различных объектов и в то же самое время 
обеспечивать когерентную общую модель. Именно это и делает система СІоЪе. 

Необычность системы СІоЪе заключается также в том, что, подобно техноло¬ 
гии ЭВМ, она основывается на модели распределенной совместно используемой 
памяти, но применительно ко всемирному контексту. В принципе использование 
нормальной технологии И5М, основанной на страницах, будет работать и в миро¬ 
вых масштабах, но вот производительность такой системы будет просто ужасной, 
поэтому в системе СІоЪе применяется другой подход. Концептуально основная 
идея состоит в том, что мир полон объектов, каждый из которых содержит некое 
(скрытое) состояние и методы, обеспечивающие управляемый доступ к этому со¬ 
стоянию. Чтобы создать совместно используемую память в мировом масштабе, 
нужно запретить прямой доступ к внутреннему состоянию объекта при помощи 
команд ШАЪ и 5Т0КЕ и разрешить весь доступ только через методы. Так как объект 
системы СІоЪе может одновременно активно использоваться многими процесса¬ 
ми, он также называется распределенным совместно используемым объектом. 
Положение системы типа СІоЪе показано на рис. 8.22, в. 

Рассмотрим теперь реализацию масштабируемости и гибкости. У каждого объек¬ 
та системы СІоЪе есть объект класса, содержащий программы его методов. У каж¬ 
дого объекта также есть интерфейс или несколько интерфейсов, каждый из кото¬ 
рых содержит пары (указатель на метод, указатель на состояние). Таким образом, 
имея интерфейс объекта, представляющий собой таблицу указателей, находящу¬ 
юся в памяти во время исполнения, процесс может вызвать п -й метод, обратив¬ 
шись к процедуре, на которую указывает п -я пара в таблице интерфейса, и пере¬ 
дав ей соответствующий указатель на состояние в качестве параметра. Указатель 
на состояние нужен на тот случай, если в памяти одновременно присутствуют, на¬ 
пример, два объекта класса шаіІЪох (почтовый ящик). У каждого объекта при этом 
есть собственный интерфейс и указатели состояния, но у обоих объектов общие 
указатели методов (рис. 8.38). В данном примере у процесса есть два открытых 
почтовых ящика, совместно использующих четыре метода, но каждый со своим 
собственным состоянием (сообщениями, сохраняемыми в экземпляре почтово¬ 
го ящика). Например, один почтовый ящик может быть для деловой переписки, 
а другой — для личной корреспонденции. 

Хранение интерфейсов во время исполнения в таблицах в памяти означает, что 
объекты не ограничены использованием какого-либо одного языка. Такое реше- 
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ние было выбрано, так как во всемирной системе будет множество различных 
пользователей и программистов со своими языковыми предпочтениями. Методы 
объектов могут быть написаны на С, С++, }аѵа или даже на ассемблере, если так 
пожелает владелец объекта. Цель интерфейсов состоит в том, чтобы скрывать от 
процессов то, что располагается за указателями методов. Такой комбинированный 
метод является более гибким, чем использование только одного языка програм¬ 
мирования (например, только С++ или только }аѵа), применяющийся в некото¬ 
рых системах. 


Адресное пространство 



Рис. 8.38. Структура объекта СІоЬе 


Чтобы использовать объект СІоЬе, процесс должен сначала связаться с ним, для 
чего этот объект нужно найти и определить хотя бы один адрес контакта (напри¬ 
мер, ІР-адрес и порт). Проверка безопасности производится во время связывания, 
и если процессу разрешено связывать этот объект, объект класса (то есть програм¬ 
ма) загружается в адресное пространство процесса, создается экземпляр класса и 
процессу возвращается указатель на его (стандартный) интерфейс. При помощи 
указателя на интерфейс процесс может вызывать методы, оперируя данным экземп¬ 
ляром объекта. В зависимости от объекта его состояние может быть состоянием 
по умолчанию или копией его текущего состояния, взятого у одной из уже суще¬ 
ствующих копий. 

Представим себе простейший объект. У этого объекта есть целое число в каче¬ 
стве состояния и два метода: геасі (чтение) и тюгііе (запись), оперирующие с этим 
целым числом. Если несколько процессов в разных странах одновременно связы¬ 
ваются с этим объектом, у всех них будет интерфейсная таблица, указывающая на 
объект класса, содержащий два метода (загружаемая во время связывания), как 
показано на рис. 8.39. У каждого процесса (потенциально) также есть копия цело¬ 
го числа, содержащего состояние объекта. Каждый метод геасі реализуется локаль¬ 
но, но вызов метода хюгііе более сложен. Если объект хочет поддерживать последо¬ 
вательную непротиворечивость, для этого требуется специальный механизм. 
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Объект класса 



Компьютер 3 Компьютер 4 

Рис. 8.39. Распределенный совместно используемый объект, состояние которого 
копируется на несколько компьютеров 


Один из вариантов такого механизма заключается в наличии процесса, называе¬ 
мого задатчиком последовательности, чья работа состоит в выдаче последователь¬ 
ных номеров при обращении к нему. Чтобы выполнить операцию записи, метод 
тгііе сначала получает последовательный номер, после чего при помощи многоад¬ 
ресной рассылки распространяет сообщение, содержащее этот порядковый номер, 
имя операции и параметр всем остальным процессам, связанным с этим объектом. 
Если два процесса одновременно вызовут метод тюгііе , они получат разные порядко¬ 
вые номера. Все процессы должны выполнять входящие методы в порядке номеров, 
а не в порядке их получения. Если процесс получит сообщение с порядковым номе¬ 
ром 26, тогда как предыдущий порядковый номер был 24, он должен ждать сообще¬ 
ния с номером 25, прежде чем выполнить 26-е. Если 25-е сообщение не появится 
в течение определенного времени, процесс должен предпринять специальные дей¬ 
ствия по его обнаружению и получению. Такая схема гарантирует, что все опера¬ 
ции записи выполнены в одинаковом порядке со всеми репликами объекта, обес¬ 
печивая последовательную непротиворечивость. 

Технически схема вполне работоспособна, но не всем объектам нужна последо¬ 
вательная непротиворечивость. Рассмотрим, например, объект, содержащий бирже¬ 
вые цены. Если участник рынка ценных бумаг на бирже 1 издает команду обнов¬ 
ления цен, а одновременно с ним участник рынка ценных бумаг на бирже 2 делает 
то же самое, то нет необходимости выполнять обновления всех копий этих объек¬ 
тов в том же порядке, так как они независимы. Вероятно, будет достаточно просто 
поместить все обновления в поток обновлений в том порядке, в котором они были 
посланы, но для этого не требуется единый задатчик последовательности. Достаточ¬ 
но использовать порядковые номера сообщений, проставляемые отправителями. 

Приведенная выше схема репликации с равными копиями реплицированного 
объекта и разрешением обновления только после получения порядкового номера 
представляет собой лишь один из многих вариантов репликационных протоколов. 
В другом варианте хранится одна эталонная (главная) копия для каждого объекта 
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плюс несколько подчиненных копий. Все обновления посылаются эталону, который 
выполняет обновление и рассылает новое состояние всем подчиненным копиям. 

Третья стратегия репликации объекта заключается в том, что состояние может 
быть только у одной копии объекта, тогда как все остальные копии являются замес¬ 
тителями объекта, не имеющими собственного состояния. Когда такой заместитель 
(например, клиентская машина) получает запрос метода геасі или гтіе , он переад¬ 
ресовывает этот запрос копии, хранящей состояние, и запрос выполняется там. 

Преимущество системы СІоЪе состоит в том, что каждый объект может иметь 
свою стратегию репликации. Одни объекты могут использовать активную репли¬ 
кацию, тогда как другие объекты могут применять репликацию типа «главный- 
подчиненный» и т. д. Кроме того, у каждого объекта может быть своя стратегия 
обеспечения непротиворечивости, создания и удаления реплик, безопасности 
и т. п. Такая независимость достигается благодаря тому, что все стратегии реали¬ 
зуются внутри объекта. Пользователи объекта и администраторы системы даже не 
знают о стратегиях объекта. Этот подход радикально отличается от применяе¬ 
мого в системе СОК.ВА, которая не скрывает стратегии, содержащиеся в объектах. 
В системе СОКВА сложно создать 1000 объектов с 1000 различных стратегий. 

Реализация объекта СІоЪе показана на рис. 8.40. На рисунке изображены под¬ 
объекты, из которых состоит объект СІоЬе. Управляющий объект принимает вы¬ 
зовы методов и использует другие подобъекты для их выполнения. Семантичес¬ 
кий подобъект выполняет работу, требуемую интерфейсом объекта. Программист, 
создающий объект, должен написать только часть программы объекта. Все ос¬ 
тальное берется из стандартных библиотек, если только программист не хочет 
реализовать новую, еще не доступную стратегию. Решшкационный подобъект за¬ 
нимается репликацией. Этот модуль может быть заменен, если вместо активной 
репликации желательно использовать репликацию типа «главный-подчиненный» 
или какую-либо другую репликационную стратегию, не затрагивая при этом 
остальной объект. Подобным же образом для реализации новой стратегии без¬ 
опасности можно заменить подобъект безопасности, а для смены протокола 
(например, ІР ѵ4 на ІР ѵб) можно заменить подобъект связи, и это не повлияет на 
остальные объекты. 

Чтобы понять, как взаимодействуют данные подобъекты, рассмотрим, что полу¬ 
чится, когда вызывается один из методов объекта. Программа, на которую указыва¬ 
ет интерфейс, представляет собой управляющий подобъект, который просит под¬ 
объект репликации выполнить необходимые действия. Если объект реплицируется 
активно, сначала получается порядковый номер. Затем подобъект репликации ве¬ 
лит всем репликам (включая собственную) выполнить работу, вызывая их семан¬ 
тические объекты. Если тип объекта «главный-подчиненный», а вызываемый метод 
находится на подчиненном объекте, то главному объекту посылается сообщение 
и т. д. В определенные моменты объект безопасности выполняет проверку (разре¬ 
шен ли вызов метода, должны ли быть зашифрованы исходящие данные и т. д.). 

Ключевым элементом системы СІоЪе является служба обнаружения, позво¬ 
ляющая находить объект, где бы тот ни находился. Служба обнаружения стро¬ 
ится в виде дерева, в узлах которого хранятся регистрационные данные объектов. 
Указатели на эти узлы передаются вверх по дереву, поэтому всегда можно найти 
сведения об объекте. Чтобы такая схема могла работать даже с мобильными объек- 
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тами, используются различные методы, включая группирование узлов дерева, 
кэширование и т. д. [20, 338,339]. 



Промежуточное программное обеспечение, 
основанное на координации 

Последняя парадигма для распределенных систем называется промежуточным 
программным обеспечением, основанным на координации. Мы начнем изучение 
данной модели с системы Ьіпсіа, научно-исследовательского проекта, давшего 
начало данному направлению, а затем рассмотрим два коммерческих примера, на 
которые система Ьіпсіа оказала большое влияние: модель «публикация/подписка» 
и систему ^Дпі. 

Ыпсіа 

Ьіпсіа представляет собой новую систему связи и синхронизации, разработанную 
в Йельском университете Дэвидом Гелернтером и его студентом Ником Каррье- 
ро [55, 56,125]. В системе Ьіпсіа независимые процессы общаются через абстрак¬ 
тное пространство кортежей. Это пространство является глобальным по отно¬ 
шению ко всей системе, и процессы на любой машине могут вставлять кортежи 
в пространство кортежей или удалять их из него, независимо от того, как и где 
они хранятся. Для пользователя пространство кортежей выглядит как большая 
глобальная общая память, что мы уже видели ранее в различных формах (напри¬ 
мер, на рис. 8.22, в). 

Кортеж представляет собой структуру языка С или запись языка Разсаі. Он 
состоит из одного или нескольких полей, каждое из которых является значением 
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некоторого типа, поддерживаемого базовым языком. (Система Еіпсіа реализуется 
с помощью добавления библиотеки к стандартному языку, например к С.) В сис¬ 
теме С-Ьіпсіа типы полей включают целые числа, длинные целые числа, числа 
с плавающей точкой, а также составные типы, такие как массивы (включая стро¬ 
ки) и структуры (но не другие кортежи). В отличие от объектов кортежи представ¬ 
ляют собой чистые данные, они не содержат методов. В листинге 8.1 показаны три 
примера кортежей. 

Листинг 8.1 . Три примера кортежей системы Спсіа 
("аЬс". 2. 5) 

ГтаГпх-Г, 1. 6. 3.14) 

(’ТатіІу". "із-зізіег” , "БіерЬапу", "КоЬегІа") 

С кортежами можно выполнять четыре операции. Первая из них, оиі, помеща¬ 
ет кортеж в пространство кортежей. Например, 

оіЛС’аЬс". 2. 5): 

помещает кортеж ("аЪс", 2, 5) в пространство кортежей. Полями операции оиі, как 
правило, являются константы, переменные и выражения, как, например, команда 

оиіС'шаігіх-І" . і, 1. 3.14); 

которая выводит в пространство кортежей кортеж ("таігіх-1 ", і , ], 3.14), состоящий 
из четырех полей, второе и третье из которых определяются текущими значения¬ 
ми переменных і и). 

Кортежи можно получить из пространства кортежей при помощи примитива іп. 
Они адресуются по содержимому, а не по имени или адресу. Поля примитива іп 
могут быть выражениями или формальными параметрами. Рассмотрим, например, 
команду 

іпС'аЬс", 2, ?і); 

Эта операция «ищет» в пространстве кортежей кортеж, состоящий из строки 
"аЬс", целого числа 2 и третьего поля, содержащего любое целое число (предпола¬ 
гается, что і целое число). Если такой кортеж обнаруживается, он удаляется из 
пространства кортежей и переменной і присваивается значение третьего поля. 
Поиск соответствия и удаление из пространства кортежей представляют собой 
единую неделимую операцию, поэтому, если два процесса одновременно выпол¬ 
няют одинаковую операцию іп, только для одного из них она завершается успеш¬ 
но (если только в пространстве кортежей не находится одновременно несколько 
кортежей, соответствующих искомому шаблону). В пространстве кортежей может 
содержаться даже несколько копий одного и того же кортежа. 

Алгоритм проверки соответствия, используемый примитивом іп, прост. Поля 
примитива, называемые шаблоном, сравниваются с соответствующими полями 
каждого кортежа в пространстве кортежей. Соответствие считается установлен¬ 
ным при выполнении трех следующих условий: 

1. У шаблона и кортежа одно и то же число полей. 

2. Типы соответствующих полей совпадают 

3. Каждая константа или переменная шаблона соответствует полю кортежа. 
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Формальные параметры, указанные знаком вопроса, за которым следует имя 
или тип переменной, не участвуют в сравнении (сравнивается только тип), но по¬ 
сле успешного завершения операции поиска переменным присваивается соответ¬ 
ствующее значение. 

Если искомого кортежа найти не удается, запрашивающий процесс приостанав¬ 
ливается до тех пор, пока другой процесс не поместит в пространство кортежей 
нужный кортеж. Автоматическая блокировка и разблокирование процесса озна¬ 
чает, что не имеет значения, которая операция будет выполнена раньше, операция 
ввода или вывода. Разница заключается только в наличии задержки, если ввод 
будет выполнен раньше вывода. 

Блокирование процесса при отсутствии необходимого ему кортежа может ис¬ 
пользоваться по-разному. Например, с помощью этого свойства можно реализо¬ 
вать семафоры. Чтобы создать семафор или выполнить операцию ир на семафоре 5, 
процесс может выполнить команду 

оиГС'зетарИоге 5"); 

А чтобы выполнить операцию сіомп, процесс должен вызывать примитив 

іпГгетарИоге 5"): 

Состояние семафора 5 определяется числом кортежей ("зетарЬоге 5") в про¬ 
странстве кортежей. Если нет ни одного семафора, любая попытка получить его 
приведет к блокировке процесса, пока какой-либо другой процесс не создаст та¬ 
кой кортеж. 

Помимо операций оиі и іп, в системе Ьіпсіа есть примитив геай, который анало¬ 
гичен примитиву іп, но не удаляет кортеж из пространства кортежей. Также име¬ 
ется примитив еѵаі, оценивающий параметры и помещающий результат в виде 
кортежа в пространство кортежей. Этот механизм может использоваться для вы¬ 
полнения произвольных вычислений. С его помощью в системе Ьіпсіа могут со¬ 
здаваться параллельные процессы. 

Публикация/подписка 

Наш следующий пример модели, основанной на координации, был создан под 
влиянием системы Ьіпсіа и называется «публикация/подписка» [251]. Эта мо¬ 
дель состоит из нескольких процессов, соединенных широковещательной сетью. 
Каждый процесс может производить информацию, потреблять информацию или 
и то и другое. 

г Когда у производителя информации есть новая информация (например, новые 
биржевые сводки), он рассылает ее всем по сети в виде кортежа. Это действие на¬ 
зывается публикацией. Каждый кортеж содержит иерархически структурирован¬ 
ную строку темы публикации с полями, разделенными точками. Процессы, кото¬ 
рых интересуют определенные темы, могут подписаться на них. При этом можно 
использовать символ звездочки для обозначения всех разделов какой-либо темы. 
Чтобы подписаться на какую-либо тему, нужно сообщить ее специальному демо¬ 
ну кортежей, работающему на той же машине, что и процесс. 

Реализация модели «публикация/подписка» показана на рис. 8.41. Когда у про¬ 
цесса есть кортеж для публикации, он рассылает его с помощью широковещания 



Распределенные системы 


633 


по локальной сети. Демон кортежей на каждой машине копирует все рассылаемые 
подобным образом кортежи в ОЗУ. Затем он просматривает строку темы сообще¬ 
ния, чтобы определить, которые процессы заинтересованы в получении этой ин¬ 
формации, пересылая каждому такому процессу копию полученного сообщения. 
Кортежи также могут рассылаться по глобальным сетям или по Интернету. Для 
этого в каждой локальной сети одна машина должна исполнять роль информаци¬ 
онного маршрутизатора, собирая все опубликованные кортежи и пересылая их 
другим локальным сетям, реализуя, таким образом, широковещание. При этом 
можно учитывать наличие в локальной сети-получателе хотя бы одного заинтере¬ 
сованного подписчика, дабы не занимать зря линии передачи. Для этого информа¬ 
ционные маршрутизаторы должны обмениваться информацией о подписчиках. 

Производитель 



Информационный 

маршрутизатор 


Рис. 8.41. Архитектура модели «публикация/подписка» 

В данной модели могут быть реализованы различные типы семантики, вклю¬ 
чая надежную доставку и гарантированную доставку, даже в случае сбоев компь¬ 
ютеров. В последнем случае необходимо хранить старые кортежи на случай, если 
они понадобятся впоследствии. Они могут храниться в базе данных, которая под¬ 
писывается на все темы кортежей. Это может быть выполнено при помощи упако¬ 
вывания базы данных в адаптер, чтобы имеющаяся база данных могла работать в 
модели «публикация/подписка». По мере поступления кортежи перехватывают¬ 
ся адаптером и помещаются в базу данных. 

Модель «публикация/подписка» полностью отделяет производителей от потре¬ 
бителей, как и система Ііпсіа. Однако иногда бывает полезно наличие обратной свя¬ 
зи. Для этого можно опубликовать кортеж с вопросом: «Кого интересует темах?» 
Ответы поступают обратно в виде кортежей вида «Меня интересует темах». 

Лпі 

В течение 50 лет архитектура компьютеров была процессоро-центричной, то есть 
компьютер представлял собой автономное устройство, состоящее из центрального 
процессора, оперативной памяти и почти всегда устройства хранения информации 
большой емкости, то есть диска. Система Діпі (произносится «джини», что звучит 
так же, как и §епіе, то есть джин, гений), созданная корпорацией 5ип Місгозузіетз, 
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явилась попыткой заменить сложившуюся модель моделью, в центре которой на¬ 
ходится сеть. 

Система^ш состоит из большого количества самодостаточных }іпі-устройств, 
каждое из которых предлагает другим устройствам одну услугу или несколько 
видов услуг. фпі -устройство может быть установлено в сеть и мгновенно начать 
предоставление услуг без сложных процедур установки. Обратите внимание, что 
устройства устанавливаются не в компьютер, как в традиционном случае, а в сетъ. 
^пі-устройство может быть традиционным компьютером, но также принтером, 
палмтопом, сотовым телефоном, телевизором, стереокомбайном или другим уст¬ 
ройством с центральным процессором, оперативной памятью и (возможно, беспро¬ 
водным) соединением с сетью. Система .фпі представляет собой свободную феде¬ 
рацию ^пі-устройств, которые могут входить в систему и выходить из системы по 
своему желанию, без централизованного управления. 

Когда ^пі-устройство хочет присоединиться к федерации, оно передает по ло¬ 
кальной сети с помощью широковещания пакет с вопросом о наличии в данном 
районе службы поиска. Для нахождения службы поиска используется специаль¬ 
ный протокол обнаружения, один из нескольких «зашитых» протоколов системы 
фпі. (В качестве альтернативы новое фпі -устройство может ждать, пока не придет 
одно из периодически рассылаемых объявлений службы поиска, но этот механизм 
не будет рассматриваться здесь.) 

Когда служба поиска видит, что новое устройство хочет зарегистрироваться, 
она посылает в ответ программу, выполняющую регистрацию. Поскольку }іпі 
представляет собой систему, целиком реализованную на языке ^ѵа, посылаемая 
программа также написана на языке ^ѵа, интерпретируемом виртуальной машиной 
фіѵа (}ѴМ, ,)аѵа Ѵігіиаі МасЬіпе). Каждое фпі-устройство должно уметь исполнять 
программы, написанные на языке ^ѵа, как правило, в режиме интерпретации. За¬ 
тем новое устройство исполняет полученную программу, связывающуюся со служ¬ 
бой поиска и регистрирующуюся в ней на некий установленный интервал времени. 
Пока не истек данный интервал времени, устройство может перерегистрировать¬ 
ся, если оно того пожелает. Такая схема означает, что ^пі-устройство может поки¬ 
нуть систему, просто выключившись, и о существовании этого устройства систе¬ 
ма вскоре забудет. Таким образом, не требуется ни специальной процедуры выхода 
из системы, ни централизованного управления. Концепция регистрации на опре¬ 
деленный срок называется получением аренды. 

Обратите внимание, что поскольку программа регистрации устройства загру¬ 
жается в устройство по сети, эта программа может изменяться по мере развития 
системы, для чего не потребуется изменений аппаратного и программного обеспе¬ 
чения в самом устройстве. В самом деле, устройству даже не известен протокол 
регистрации. Оно знает только о части этого протокола, касающейся предоставле¬ 
ния некоторых атрибутов и прокси-кода, которым в дальнейшем будут пользовать¬ 
ся другие устройства для доступа к устройству. 

Устройство или пользователь, ищущие определенную службу, могут запросить 
о ней поисковую службу. При успешном запросе прокси, предоставленный уст¬ 
ройством во время регистрации, отсылается запрашивающему устройству и запус¬ 
кается на нем для установления контакта. Таким образом, устройство или пользо¬ 
ватель могут общаться с другим устройством, даже не зная его адреса и протокола. 
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Клиенты и службы (аппаратные или программные устройства) общаются и 
синхронизируются при помощи пространств ^ѵаЗрасез, спроектированных по 
образу пространства кортежей системы Ьіпсіа, но обладающими существенными 
отличиями от него. Каждое пространство ^ѵаЗрасе состоит из некоторого количе¬ 
ства элементов строго определенных типов. Эти элементы напоминают кортежи 
системы Ьіпсіа с тем отличием, что их тип жестко задан, тогда как кортежи систе¬ 
мы Ьіпсіа не имеют типов. Каждый элемент состоит из нескольких полей, каждое 
из которых имеет определенный тип языка ^ѵа. Например, элемент типа служа¬ 
щий может состоять из строки (для имени), целого числа (номер отдела), второго 
целого числа (телефон) и логической переменной, означающей, работает ли дан¬ 
ный служащий полный рабочий день. 

В пространстве ^ѵаЗрасе определены всего четыре метода (хотя у двух из них 
есть подвиды): 

1. ѴѴТііе (записать): поместить новый элемент в пространство ^ѵаЗрасе. 

2. КеасІ (прочитать): копировать элемент, соответствующий шаблону из про¬ 
странства ^ѵаЗрасе. 

3. Таке (взять): копировать и удалить элемент, соответствующий шаблону из 
пространства ^ аѵаЗрасе. 

4. Г^ойіу (уведомить): уведомить вызывающее устройство, когда в простран¬ 
ство фіѵаЗрасе записывается элемент, соответствующий шаблону. 

Метод тгііе принимает в качестве входных аргументов элемент и его срок арен¬ 
ды, то есть время, когда этот элемент должен быть уничтожен. В системе Ьіпсіа, 
напротив, кортежи остаются в пространстве кортежей, пока их не удалят. В про¬ 
странстве ^ѵаЗрасе один и тот же элемент может содержаться несколько раз, так 
что пространство ^ѵаЗрасе не является математическим множеством (как и про¬ 
странство кортежей системы Ьіпсіа). 

Методам геа<1 и Іаке необходимо задать в качестве параметра шаблон для поиска 
элемента. Каждое поле шаблона может содержать определенное указанное значе¬ 
ние, которому должно соответствовать поле элемента или знак звездочки, означа¬ 
ющий, что данное значение при поиске безразлично, а сравниваются только типы 
переменных. Если подходящий под шаблон элемент найден, он возвращается вы¬ 
зывающему устройству, а в случае метода Іаке еще и удаляется из пространства 
ф'іѵаЗрасе. У каждого из этих методов фіѵа5 расе есть два варианта, отличающихся 
поведением метода в случае отсутствия элемента, соответствующего шаблону. Один 
вариант метода немедленно возвращает сообщение об ошибке поиска, а другой ждет 
в течение определенного интервала времени (задаваемого в качестве параметра). 

Метод поіі/у регистрирует интерес в определенном шаблоне. Если когда-либо 
позднее появляется элемент, соответствующий шаблону, запускается метод поіі]~у 
вызывавшего устройства. 

В отличие от пространства кортежей Ьіпсіа, пространство ^ѵаЗрасе поддержи¬ 
вает атомарные транзакции. С их помощью можно группировать несколько мето¬ 
дов. Они либо все выполняются, либо не выполняется ни один из них. Во время 
транзакции изменения, производимые в пространстве ^ѵаЗрасе, не видны вне 
транзакции. Только когда транзакция завершается, эти изменения становятся вид¬ 
ны остальным пользователям. 
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Пространство ^ѵаЗрасе может использоваться для синхронизации между 
общающимися процессами. Например, в ситуации «производитель-потребитель» 
производитель помещает элементы в пространство^ѵаЗрасе по мере их производ¬ 
ства. Потребитель забирает их методом Іаке, блокируясь, если нужного ему эле¬ 
мента нет. Пространство ^ѵаЗрасе гарантирует атомарность выполнения каждо¬ 
го метода, поэтому невозможна ситуация, при которой процесс пытается прочитать 
элемент, созданный всего лишь наполовину. 


Исследования в области 
многопроцессорных систем 

В данной главе мы рассмотрели три типа многопроцессорных систем: мульти¬ 
процессоры, многомашинные системы и распределенные системы. Познакомим¬ 
ся теперь с исследованиями в данных трех областях. Большая часть исследований 
в области мультипроцессоров относится к аппаратному обеспечению, в частности 
к способам построения совместно используемой памяти и методам поддержания 
ее в согласованном состоянии. Тем не менее существуют и исследования в этой 
области, посвященные использованию мониторов виртуальной машины на мульти¬ 
процессорах [48] и управлению ресурсами мультипроцессоров [133]. Планирование 
потоков также составляет предмет исследований, как в плане алгоритмов плани¬ 
рования [16, 267], так и в плане обработки очереди запросов на запуск [84]. 

Создание многомашинных систем существенно проще построения мультипро¬ 
цессоров. Все, что требуется, — это несколько персональных компьютеров или ра¬ 
бочих станций и высокоскоростная сеть. По этой причине многомашинные систе¬ 
мы представляют собой популярную тему исследований в университетах. Большая 
часть работ посвящена распределенной памяти общего доступа в той или иной 
форме, как основанной на страничной организации, текущем каталоге и реализуе¬ 
мой чисто программно [57, 114, 163, 165, 294, 315]. Оптимизация связи на уров¬ 
не пользователя [347] и балансировка нагрузки [144] также являются темами 
исследований. 

Множество статей посвящено распределенным системам, например кэширова¬ 
нию \ѵеЬ-страниц [360], распределенным файловым системам [8, 148, 329] и мо¬ 
бильным файловым системам [298]. 


Резюме 

Производительность и надежность компьютерных систем могут быть существен¬ 
но увеличены при использовании многопроцессорных систем. Тремя типами орга¬ 
низации многопроцессорных систем являются мультипроцессоры, многомашин¬ 
ные системы и распределенные системы. 

Мультипроцессор состоит из двух или более центральных процессоров, совме¬ 
стно пользующихся общей оперативной памятью. Эти центральные процессоры 
могут быть соединены шиной, координатным коммутатором или многоступенча¬ 
той коммутаторной сетью. Возможно применение различных конфигураций опе- 
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рационных систем, включая наличие собственной операционной системы у каж¬ 
дого центрального процессора, наличие одной главной операционной системы и 
нескольких подчиненных операционных систем или симметричного мультипро¬ 
цессора с одной копией операционной системы, способной выполняться на любом 
центральном процессоре. В последнем случае для обеспечения синхронизации 
требуется использование блокировок. Когда блокировка недоступна, центральный 
процессор может ждать ее освобождения в цикле опроса или выполнить пере¬ 
ключение контекста. Возможно применение различных алгоритмов планирова¬ 
ния, включая разделение времени, разделение памяти и бригадное планирование. 

Многомашинные системы также состоят из двух и более центральных процес¬ 
соров, но у каждого из этих центральных процессоров есть своя собственная па¬ 
мять. У них нет общей оперативной памяти, поэтому весь обмен информацией осу¬ 
ществляется при помощи передачи сообщений. В некоторых случаях на сетевой 
интерфейсной плате установлен свой процессор. В таких случаях необходимо тща¬ 
тельно организовать связь центрального процессора и процессора на плате во из¬ 
бежание конфликтов. Для связи на уровне пользователя на многомашинных сис¬ 
темах часто применяется вызов удаленной процедуры, но распределенная память 
совместного доступа также может использоваться. Здесь важным вопросом явля¬ 
ется балансировка нагрузки процессов. Среди многочисленных применяемых для 
этого алгоритмов применяются такие, как алгоритмы, инициируемые отправите¬ 
лем, алгоритмы, инициируемые получателем, и алгоритмы торгов. 

Распределенные системы представляют собой слабосвязанные системы, каждый 
узел которых является полноценным компьютером с полным набором периферий¬ 
ных устройств и собственной операционной системой. Часто такие системы распре¬ 
делены по большим территориям. Поверх операционной системы может устанав¬ 
ливаться промежуточное программное обеспечение, предоставляющее однородный 
уровень для взаимодействующих с ним приложений. Среди различных типов про¬ 
межуточного программного обеспечения — документное, файловое, объектное и 
координационное. В качестве примера промежуточного программного обеспече¬ 
ния можно назвать такие системы, как Всемирная паутина, АЕ5, СОКВА, СІоЪе, 
Ілпсіа и Діпі. 


Вопросы 

1. Можно ли систему сетевых новостей ІІ5ЕКЕТ или проект 5ЕТІ@Ьоте счи¬ 
тать распределенной системой? (Проект 5ЕТІ@Іюте использует несколько 
миллионов персональных компьютеров для анализа данных, получаемых с 
радиотелескопа с целью поиска внеземного разума.) Если да, к каким кате¬ 
гориям, описанным на рис. 8.1, они относятся. 

2. Что произойдет, если два центральных процессора на мультипроцессоре по¬ 
пытаются одновременно получить доступ к одному и тому же слову памяти? 

3. Если центральный процессор при каждой команде совершает одно обраще¬ 
ние к памяти, сколько понадобится центральных процессоров, работающих 
со скоростью 200 МІРЗ, чтобы насытить шину с частотой 400 МГц? Пред¬ 
положим, что для обращения к памяти требуется один цикл шины. Теперь 
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рассмотрите ту же задачу для системы, в которой используется кэширова¬ 
ние, и частота попаданий кэша составляет 90 %. Наконец, какая потребует¬ 
ся частота попаданий кэша, чтобы той же шиной могли совместно пользо¬ 
ваться 32 центральных процессора, не перегружая шину? 

4. Предположим, что порвется провод между коммутаторами 2А и ЗВ в сети 
омега (см. рис. 8.5). Кто от кого окажется отрезанным? 

5. Как выполняется обработка сигнала в модели на рис. 8.7? 

6. При обращении к системному вызову в модели на рис. 8.8 сразу после пре¬ 
рывания должна быть решена проблема, которой не было в модели на 
рис. 8.7. Какова природа этой модели и каковы способы ее решения? 

7. Перепишите программу епіег_ге§іоп из листинга 2.2, используя чистое 
чтение, чтобы уменьшить пробуксовку системы, вызываемую применением 
команды Т5Ц. 

8. Действительно ли необходимы критические области в программных секци¬ 
ях в операционной системе 5МР для предотвращения конфликтов или до¬ 
статочно мьютексов в структурах данных? 

9. При применении команды Т$І- для синхронизации мультипроцессора блок 
кэша, содержащий мьютекс, будет мотаться взад-вперед между центральным 
процессором, удерживающим блокировку, и центральным процессором, 
запрашивающим ее, если оба процессора изменяют содержимое блока. Для 
снижения шинного трафика запрашивающий центральный процессор вы¬ 
полняет команду Т51. раз в 50 циклов шины, но центральный процессор, удер¬ 
живающий блокировку, изменяет блок кэша между командами Т$І_. Если 
блок кэша состоит из 16 32-разрядных слов, для переноса каждого из кото¬ 
рых требуется один цикл шины, а шина работает с частотой 400 МГц, какая 
часть пропускной способности шины съедается перемещением блока кэша 
взад-вперед? 

10. В тексте предполагалось использование алгоритма двоичного экспоненци¬ 
ального отката между вызовами команды Т5І_ для опроса блокировки. Так¬ 
же предлагалось использовать максимальное значение интервала ожидания 
между опросами. Будет ли алгоритм правильно работать без ограничения 
интервала ожидания? 

11. Предположим, что у процессоров нет команды Т$І_ для синхронизации муль¬ 
типроцессора. Вместо нее предлагается использовать команду $МР, атомарно 
меняющую содержимое регистра и ячейки памяти. Может ли эта команда 
использоваться для обеспечения синхронизации мультипроцессора? Если 
да, то как? Если нет, то почему? 

12. В данном задании вам предлагается сосчитать, какую нагрузку на шину ока¬ 
зывает спин-блокировка. Допустим, что выполнение каждой команды про¬ 
цессора занимает 5 нс. Когда команда выполнена, выполняются все необхо¬ 
димые циклы шины. Каждый цикл шины занимает дополнительно 10 нс. 
Какую часть пропускной способности шины потребляет процесс, выполня¬ 
ющий в цикле команду Т$І_, чтобы войти в критическую область? Предполо¬ 
жим, что работает нормальное кэширование, поэтому сама выборка коман¬ 
ды Т51. не потребляет циклов шины. 
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13. Как было сказано, рис. 8.12 иллюстрирует среду разделения времени. Поче¬ 
му только один процесс (А) показан на рис. 8.12, б? 

14. Родственное планирование снижает частоту промахов кэша. Снижается ли при 
этом также частота промахов ТЬВ? А как насчет страничных прерываний? 

15. Чему равен диаметр соединительной сети для каждой из топологий, изобра¬ 
женных на рис. 8.16? Учитывайте одинаково все транзитные участки, и меж¬ 
ду хостом и маршрутизатором, и между двумя маршрутизаторами. 

16. Рассмотрите топологию двойного тора (см. рис. 8.16, г), расширенного до 
размера к х к. Чему равен диаметр сети? Подсказка, рассматривайте четные 
и нечетные значения к отдельно. 

17. Для измерения пропускной способности соединительной сети часто приме¬ 
няется метод бисекции. Для этого из сети удаляется минимальное количество 
связей, так чтобы сеть распалась на две части. Затем суммируется пропускная 
способность удаленных линий связи. Если способов разбиения сети несколь¬ 
ко, выбирается тот, при котором эта сумма минимальна. Чему равна бисекци¬ 
онная пропускная способность соединительной сети, представляющей со¬ 
бой куб 8x8x8, если пропускная способность каждой линии равна 1 Гбайт? 

18. Представим себе многомашинную систему, в которой сетевой интерфейс 
работает в режиме пользователя, поэтому для перемещения данных из ОЗУ 
источника в ОЗУ приемника требуется всего три операции копирования. 
Предположим, что перемещение 32-разрядного слова через сетевой интер¬ 
фейс занимает 20 нс, а сама сеть работает со скоростью 1 Гбит/с. Чему будет 
равна задержка пересылки 64-байтового пакета без учета времени копиро¬ 
вания? Чему будет равна задержка с учетом времени копирования? Теперь 
рассмотрите случай, в котором требуются две дополнительные операции 
копирования: в ядро на передающей стороне и из ядра на принимающей сто¬ 
роне. Чему будет равна задержка в этом случае? 

19. Повторите предыдущее задание для случая с тремя операциями копирова¬ 
ния и с пятью операциями копирования, но на этот раз рассчитайте не вре¬ 
мя задержки, а пропускную способность. 

20. Чем должна отличаться реализация примитивов зепсі и гесеіѵе для мульти¬ 
процессора с общей памятью и многомашинной системы и как это отразит¬ 
ся на производительности? 

21. При переносе данных из ОЗ У в сетевую интерфейсную плату может исполь¬ 
зоваться фиксация страницы. Предположим, что выполнение системных 
вызовов для фиксации и открепления страниц занимает 1 мкс. Копирова¬ 
ние данных занимает 5 байт/нс с помощью БМА и 20 нс на байт при помо¬ 
щи программного ввода-вывода. Насколько большим должен быть пакет, 
чтобы использование фиксации страницы и использование ОМА было оп¬ 
равданным? 

22. Когда процедура вынимается из программы и переносится на другой компь¬ 
ютер, чтобы обращаться к ней в дальнейшем при помощи метода КРС (вы¬ 
зов удаленной процедуры), могут возникнуть некоторые проблемы. В тек¬ 
сте указывались четыре из них: указатели, массивы неизвестных размеров, 
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неизвестные типы параметров и глобальные переменные. Среди не обсуж¬ 
давшихся вопросов — что произойдет, если удаленная процедура обратится 
к системному вызову. Какие проблемы может это вызвать и что можно сде¬ 
лать для их разрешения? 

23. Когда в системе БЗМ происходит страничное прерывание, требуется найти 
нужную страницу. Назовите два возможных метода поиска страницы. 

24. Рассмотрите примеры распределения процессоров на рис. 8.25. Предполо¬ 
жим, что процесс Я перемещен с узла 2 в узел 3. Чему теперь равен суммар¬ 
ный внешний трафик? 

25. Некоторые многомашинные системы позволяют работающим процессам 
мигрировать с одного узла на другой. Достаточно ли для этого просто оста¬ 
новить процесс, сохранить его образ в памяти и переслать этот образ на дру¬ 
гой узел? Назовите две нетривиальные проблемы, которые следует решить, 
чтобы выполнить эту работу. 

26. Почему существует ограничение на длину кабеля в сети ЕіЬегпеІ? 

27. На рис. 8.27 третий и четвертый уровни помечены как промежуточное про¬ 
граммное обеспечение и приложение на всех четырех машинах. В чем их 
сходство и различие для всех четырех платформ? 

28. В таблице на рис. 8.30 перечислены шесть типов служб. Какая служба наи¬ 
более всего соответствует каждому из следующих приложений? 

1. Интерактивное видео по Интернету. 

2. Загрузка \ѵеЬ-страницы. 

29. НЯЗ-имена имеют иерархическую структуру, например сз.ипі.еЛи или заіез. 
§епегаІ-шісІ§еі.сат. Один из способов реализации ОНЗ-имен может заклю¬ 
чаться в поддержании централизованной базы данных, однако этот метод 
не применяется, так как такая база данных будет получать слишком боль¬ 
шой поток запросов. Предложите свой метод реализации базы данных ОЯЗ. 

30. При обсуждении метода обработки браузером ІШЬ-указателей утвержда¬ 
лось, что соединения устанавливаются через порт 80. Почему? 

31. Могут ли ШІЬ-указатели, используемые в Паутине, обладать свойством 
прозрачности местоположения? Аргументируйте свой ответ. 

32. Когда браузер получает ѵсеЪ-страницу, он сначала устанавливает ТСР-со- 
единение, чтобы получить текст страницы (на языке НТМЬ). Затем он 
разрывает соединение и изучает страницу. Если она содержит графические 
изображения, он снова создает отдельные ТСР-соединения для каждого 
изображения. Предложите две альтернативные схемы для улучшения про¬ 
изводительности. 

33. При использовании сеансовой семантики изменения файлов немедленно 
становятся видимыми процессу, инициировавшему эти изменения, и никог¬ 
да не видны процессам на других машинах. Однако вопрос о том, должны 
ли эти изменения становиться сразу же видимыми другим процессам на той 
же машине, остается открытым. Приведите аргументы в пользу обоих вари¬ 
антов ответа. 
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34. В файловой системе АР5 на клиентских машинах файлы кэшируются це¬ 
ликом. Предположим, что дисковое пространство, выделенное под кэширу¬ 
емые файлы, переполнено. Что следует делать при запросе нового файла? 
Создайте соответствующий алгоритм. 

35. В чем преимущества объектного доступа к данным перед совместно исполь¬ 
зуемой памятью в ситуации, когда нескольким процессам требуется доступ 
к данным? 

36. При выполнении операции іп для обнаружения кортежа в системе Ьіпсіа 
линейный поиск по всему пространству кортежей крайне неэффективен. 
Разработайте метод организации пространства кортежей, который ускорит 
выполнение операций іп. 

37. Для копирования буфера требуется время. Напишите программу на язы¬ 
ке С, вычисляющую данное время для системы, к которой у вас есть доступ. 
Используйте функции сіоск или Ыте$, чтобы определить, сколько времени 
занимает копирование длинного массива. Поэкспериментируйте с массива¬ 
ми различного размера, чтобы отделить время копирования от накладных 
расходов. 

38. Напишите на языке С функции, которые могли бы использоваться в каче¬ 
стве клиентского и серверного суррогатов для выполнения КРС-вызова 
стандартной функции ргіпі /, а также головной модуль для тестирования 
этих функции. Клиент и сервер должны общаться при помощи структуры 
данных, передаваемой по сети. Вы можете наложить разумные ограничения 
на длину строки формата и число, типы и размеры переменных, которые 
будет принимать ваш клиентский суррогат. 

39. Напишите две программы для моделирования балансирования нагрузки 
в многомашинной системе. Первая программа должна назначать т процессов 
п машинам, в соответствии с файлом инициализации. Каждый процесс дол¬ 
жен работать в течение случайного периода времени, величина которого 
распределена по Гауссу, причем среднее линейное и среднеквадратическое 
отклонение задаются в виде параметров модели. В конце работы каждый 
процесс создает несколько новых процессов, количество которых является 
случайной величиной, распределенной по Пуассону. После завершения ра¬ 
боты каждого процесса центральный процессор должен решить, отдать свои 
процессы другому центральному процессору или попытаться самому найти 
новые процессы. Первая программа должна использовать алгоритм, иници¬ 
ируемый отправителем, чтобы избавиться от лишней работы, если у централь¬ 
ного процессора оказывается более к процессов. Вторая программа должна 
использовать алгоритм, инициируемый получателем, чтобы получать рабо¬ 
ту, когда это необходимо. Вы можете делать любые разумные допущения, 
но должны заявлять о них открыто и четко. 




Глава 9 

Безопасность 


Многие компании обладают ценной информацией, которую они тщательно охра¬ 
няют. Эта информация может быть технической (например, архитектура новой 
микросхемы или программного обеспечения), коммерческой (исследования кон¬ 
курентоспособности или маркетинговые планы), финансовой (планы бирже¬ 
вых операций), юридической (документы о потенциальном слиянии или разделе 
фирм) и т. д. Часто эта информация защищается при помощи охранника в унифор¬ 
ме, стоящего у входа в здание и проверяющего у всех входящих в здание наличие 
определенного значка. Кроме того, многие офисы и картотечные шкафы могут за¬ 
пираться на ключ, чтобы гарантировать доступ к информации только авторизо¬ 
ванных сотрудников. 

По мере того как возрастают объемы информации, хранящейся в компьютерных 
системах, необходимость в защите информации становится все важнее. Таким об¬ 
разом, защита информации от несанкционированного доступа является главной 
заботой всех операционных систем. К сожалению, достижение этой цели стано¬ 
вится все более сложной задачей, так как стремление операционных систем к раз¬ 
дуванию все чаще воспринимается как нормальное и приемлемое явление. В сле¬ 
дующих разделах мы рассмотрим различные вопросы, связанные с безопасностью 
и защитой; некоторые из них аналогичны вопросам защиты информации реально¬ 
го мира, хранящейся в виде обычных бумажных документов, а другие являются 
уникальными для компьютерных систем. В данной главе мы изучим вопрос компь¬ 
ютерной безопасности в применении к операционным системам. 


Понятие безопасности 

Термины «безопасность» и «защита» иногда смешиваются. Тем не менее часто 
бывает полезно провести границу между общими проблемами, связанными с га¬ 
рантированием того, что файлы не читаются и не модифицируются неавторизо¬ 
ванными лицами, с одной стороны, и специфическими механизмами операцион¬ 
ной системы, используемыми для обеспечения безопасности, с другой стороны. 
Чтобы избежать путаницы, мы будем применять термин безопасность для обо¬ 
значения общей проблемы и термин механизмы защиты при описании специфи¬ 
ческих механизмов операционной системы, используемых для обеспечения ин¬ 
формационной безопасности в компьютерных системах. Однако граница между 
этими двумя терминами определена не четко. Сначала мы познакомимся с вопро- 
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сами безопасности, чтобы понять природу проблемы. Затем мы рассмотрим меха¬ 
низмы защиты и модели, способствующие обеспечению безопасности. 

Проблема безопасности многогранна. Тремя ее наиболее важными аспектами 
являются природа угроз, природа злоумышленников и случайная потеря данных. 
Все эти вопросы будут поочередно рассмотрены в этой главе. 

Угрозы 

С позиций безопасности у компьютерной системы в соответствии с наличествую¬ 
щими угрозами есть три главные задачи, показанные в табл. 9.1. Первая задача, 
конфиденциальность данных, заключается в том, что секретные данные должны 
оставаться секретными. В частности, если владелец некоторых данных решил, что 
эти данные будут доступны только определенному кругу лиц, система должна га¬ 
рантировать, что к этим данным не смогут получить доступ лица за пределами ус¬ 
тановленного круга. Как минимум владелец данных должен иметь возможность 
указать список пользователей, которым разрешено видеть ту или иную информа¬ 
цию, а система должна обеспечить исполнение этих требований. 


Таблица 9.1 . Задачи безопасности и угрозы безопасности 


Задача 

Угроза 

Конфиденциальность данных 

Демонстрация данных 

Целостность данных 

Порча или подделка данных 

Доступность системы 

Отказ обслуживания 


Вторая задача, целостность данных, означает, что неавторизованные пользо¬ 
ватели не должны иметь возможности модифицировать данные без разрешения 
владельца. Модификация данных в данном контексте означает не только измене¬ 
ние данных, но также их удаление или добавление фальшивых данных. Если систе¬ 
ма не может гарантировать, что хранящиеся в ней данные останутся неизменными 
до тех пор, пока владелец не решит их изменить, то такая система немногого стоит. 

Третья задача, доступность системы, означает, что никто не может вывести 
систему из строя. Атаки типа отказ в обслуживании становятся все более рас¬ 
пространенными. Например, если компьютер является сервером Интернета, он 
может быть затоплен мощным потоком запросов, при этом все его процессорное 
время уйдет на изучение входящих запросов. Так, если обработка запроса чтения 
\ѵеЬ-страницы занимает 100 мкс, то любой пользователь, способный послать 
10 000 запросов в секунду, может ликвидировать сервер. Существует множество 
моделей и технологий для противостояния атакам конфиденциальности и целост¬ 
ности данных. Отбивание атак типа «отказ обслуживания» является значительно 
более сложной задачей. 

Еще один аспект проблемы безопасности касается права пользователя на кон¬ 
фиденциальность личной информации. Это довольно запутанная тема, связанная 
с различными юридическими и моральными вопросами. Должно ли и имеет ли 
право правительство собирать досье на всех и каждого, чтобы поймать лиц, укло¬ 
няющихся от налогов или получающих незаконные пособия? Должна ли полиция 




644 


Глава 9. Безопасность 


иметь возможность слежки за всем и вся, пытаясь победить организованную пре¬ 
ступность? Есть ли права доступа к частной информации у работодателей и стра¬ 
ховых компаний? Что происходит, когда эти права вступают в конфликт с инди¬ 
видуальными правами граждан? Все эти вопросы имеют чрезвычайно большое 
значение, но они находятся за пределами рассмотрения данной книги. 

Злоумышленники 

Большинство людей соблюдают закон, поэтому зачем беспокоиться о безопас¬ 
ности? Все дело в том, что, к сожалению, некоторые люди не столь добродетельны 
и желают доставить другим неприятности (например, с целью получения собствен¬ 
ной коммерческой выгоды). В литературе по безопасности человека, сующего свой 
нос в чужие дела, называют злоумышленником и иногда неприятелем. Злоумыш¬ 
ленники подразделяются на два вида. Пассивные злоумышленники просто пыта¬ 
ются прочитать файлы, которые им не разрешено читать. Активные злоумышлен¬ 
ники пытаются незаконно изменить данные. При разработке защиты системы от 
злоумышленников важно представлять себе разновидности злоумышленников, от 
которых предстоит защищать систему. Наиболее распространенными категория¬ 
ми злоумышленников являются: 

1. Случайные любопытные пользователи, не применяющие специальных тех¬ 
нических средств. У многих людей есть компьютеры, соединенные с общим 
файловым сервером. И если не установить специальной защиты, благодаря 
естественному любопытству многие люди станут читать чужую электронную 
почту и другие файлы. Например, во многих системах ІІШХ новые, только 
что созданные файлы по умолчанию доступны для чтения всем желающим. 

2. Члены организации, занимающиеся шпионажем. Студенты, системные про¬ 
граммисты, операторы и другой технический персонал часто считает взлом 
системы безопасности локальной компьютерной системы личным вызовом. 
Как правило, они имеют высокую квалификацию и готовы посвящать дости¬ 
жению поставленной перед собой цели значительное количество времени. 

3. Те, кто совершают решительные попытки личного обогащения. Некоторые 
программисты, работающие в банках, предпринимали попытки украсть день¬ 
ги у банка, в котором они работали. Использовавшиеся схемы варьирова¬ 
лись от изменения способов округления сумм в программах, для сбора, та¬ 
ким образом, с миру по нитке, до шантажа («Заплатите мне, или я уничтожу 
всю банковскую информацию»), 

4. Занимающиеся коммерческим и военным шпионажем. Шпионаж представ¬ 
ляет собой серьезную и хорошо финансированную попытку конкурента или 
другой страны украсть программы, коммерческие тайны, ценные идеи и тех¬ 
нологии, схемы микросхем, бизнес-планы и т. д. Часто такие попытки вклю¬ 
чают подключение к линиям связи или установку антенн, направленных на 
компьютер для улавливания его электромагнитного излучения. 

Очевидно, что попытка предотвратить кражу военных секретов враждебным 
иностранным государством отличается от противостояния попыткам студентов 
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установить забавные сообщения в систему. Необходимые для поддержания сек¬ 
ретности и защиты усилия зависят от предполагаемого противника. 

Еще одной разновидностью угрозы безопасности, появившейся в последние 
годы, является вирус. Вирусам будет уделено особое внимание в данной главе. В об¬ 
щем случае вирус представляет собой программу, реплицирующую саму себя и (как 
правило) причиняющую тот или иной ущерб. В определенном смысле автор вируса 
также является злоумышленником, часто обладающим высокой квалификацией. 
Основное различие между обычным злоумышленником и вирусом состоит в том, 
что первый из них представляет собой человека, лично пытающегося взломать 
систему с целью причинения ущерба, тогда как вирус является программой, напи¬ 
санной таким человеком и выпущенной в свет с надеждой на причинение ущерба. 
Злоумышленники пытаются взломать определенные системы (например, сеть 
какого-либо банка или Пентагона), чтобы украсть или уничтожить определенные 
данные, тогда как вирус обычно действует не столь направленно. Таким образом, 
злоумышленника можно уподобить наемному убийце, пытающемуся уничтожить 
конкретного человека, в то время как автор вируса больше напоминает террорис¬ 
та, пытающегося убить большое количество людей, а не кого-либо конкретно. 


Случайная потеря данных 

Помимо различных угроз со стороны злоумышленников, существует опасность 
потери данных в результате несчастного случая. К наиболее распространенным 
причинам случайной потери данных относятся: 

1. Форс-мажор: пожары, наводнения, землетрясения, войны, восстания, кры¬ 
сы, изгрызшие ленты или гибкие диски. 

2. Аппаратные и программные ошибки: сбои центрального процессора, нечита¬ 
емые диски или ленты, ошибки при передаче данных, ошибки в программах. 

3. Человеческий фактор: неправильный ввод данных, неверные установленные 
диск или лента, запуск не той программы, потерянные диск или лента и т. д. 

Большая часть этих проблем может быть разрешена при помощи своевремен¬ 
ного создания соответствующих резервных копий, хранимых на всякий случай 
вдали от оригинальных данных. Хотя проблема защиты информации от случай¬ 
ных потерь кажется пустяковой по сравнению с задачей противостояния умным 
злоумышленникам, на практике больше ущерба наносят именно несчастные случаи. 


Основы криптографии 

Некоторые сведения о криптографии могут оказаться полезными для понимания 
разделов этой главы и некоторых следующих. Однако серьезное обсуждение крип¬ 
тографии выходит за рамки этой книги. Эта тема подробно рассматривается во 
многих прекрасных трудах по компьютерной безопасности. Читатели, интересую¬ 
щиеся данным вопросом, могут прочитать, например, [176, 266]. Ниже будет дан 
очень краткий обзор вопроса криптографии для читателей, совсем незнакомых 
с данной темой. 
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Задача криптографии заключается в том, чтобы взять сообщение или файл, на¬ 
зываемый открытым текстом, и преобразовать его в зашифрованный текст таким 
образом, чтобы только посвященные могли преобразовать его обратно в открытый 
текст. Для всех остальных зашифрованный текст должен представлять собой про¬ 
сто непонятный набор битов. Это может показаться странным для новичков в этой 
области, но алгоритмы (функции) шифрации и дешифрации всегда должны быть 
открытыми (публичными). Попытки удерживать их в секрете никогда не увенчи¬ 
ваются успехом и всего лишь вводят в заблуждение людей, пользующихся дан¬ 
ными алгоритмами, создавая ложную иллюзию защищенности данных. В про¬ 
мышленности такая тактика, называемая секретностью благодаря неизвестности, 
применяется только новичками в области безопасности. Как ни странно, к этой 
категории относятся многие крупные многонациональные корпорации, которым 
следовало бы иметь лучшее представление о данном вопросе. 

На самом деле секретность зависит от параметров алгоритмов, называемых 
ключами. Мы будем использовать формулу С = Е(Р, К Е ), обозначающую, что при 
зашифровке открытого текста Р с помощью ключа К получается зашифрованный 
текст С. 

Аналогично формула Р = /)( С, К 0 ) означает расшифровку зашифрованного тек¬ 
ста С для восстановления открытого текста. Схематично процессы шифрования 
и дешифровки показаны на рис. 9.1. 


Ключ шифрования 


Ключ дешифрования 


Открытый 




Шифрование 


С = Е(Р, К Е ) 


Зашифрованный текст 


(незашифрованный) Алгоритм 
текст на входе шифрования 


Р = 0(0, Кв) 


Алгоритм 

дешифрования 


Открытый 

(незашифрованный) 
текст на выходе 




Дешифрованиа 


Рис. 9.1. Открытый текст и зашифрованный текст 


Шифрование с секретным ключом 

Рассмотрим самый простой пример алгоритма шифрования, в котором каждая бук¬ 
ва заменяется другой буквой, например все символы А заменяются символами 0, все 
символы В заменяются символами \Ѵ, все символы С заменяются символами Е и т. д. 

Открытый текст: АВСОЕРОНПКІММОРОК5ТІІѴШ2 

Зашифрованный текст: ОИЕКТѴІЛОРА$ОРОНіЖІ_2ХСѴВММ 

Такая общая схема называется моноалфавитной подстановкой, ключом к ко¬ 
торой является 26-символьная строка, соответствующая полному алфавиту, то 
есть ОУУЕКТУтОРАЗПРСЩКЫХСУВММ. В нашем примере слово АТТАСК(ата¬ 
ка) будет выглядеть как 02.20ЕА. Ключ дешифрации содержит информацию о том, 
как из этого слова снова получить исходный открытый текст. В данном приме- 
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ре ключ дешифрации представляет собой КХѴМСЫОРЛ (1К52У[)АОЬЕСЛУВ ОТТ, 
так как символу А в зашифрованном тексте соответствует символ К в открытом 
тексте, символу В в зашифрованном тексте соответствует символ X в открытом 
тексте и т. д. 

На первый взгляд такая система может показаться надежной, так как даже если 
криптоаналитику известна общая система, он не знает, какой из 26! = 4х10 26 вари¬ 
антов ключа применить. Тем не менее подобный шифр легко взламывается даже 
при довольно небольших порциях зашифрованного текста. Для подбора шифра 
может быть использовано преимущество статистических характеристик естествен¬ 
ных языков. Например, в английском языке буква е встречается в тексте чаще всего. 
Следом за ней по частоте использования идут буквы I, о, а, п, і и т. д. Наиболее часто 
встречающимися комбинациями из двух символов, или биграммами, являются іН , 
іп, ег, ге и т. д. При помощи данной информации взлом такого шифра несложен. 

Многие криптографические системы, как и данная система, обладают тем свой¬ 
ством, что по ключу шифрования легко найти ключ дешифрации, и наоборот. Такие 
системы называются системами шифрования с секретным ключом или системами 
шифрования с симметричным ключом. Хотя шифры с использованием моноалфа¬ 
витной подстановки являются бесполезными, известно множество других алго¬ 
ритмов с симметричным ключом, которые относительно надежны при достаточно 
большой длине ключа. Для серьезного уровня безопасности, вероятно, следует ис¬ 
пользовать ключи длиной в 1024 бит. При такой длине ключа пространство ключей 
составит 2 1024 = 2 х ІО 308 ключей. Более короткие ключи могут остановить любите¬ 
лей, но не специальные службы развитых государств. 


Шифрование с открытым ключом 

Системы с секретным ключом эффективны, так как количество вычислений для 
шифрования и дешифрования сообщения не очень велико, но у них есть серьез¬ 
ный недостаток: и отправитель, и получатель должны оба обладать общим секрет¬ 
ным ключом. Им, возможно, даже может понадобиться физический контакт для 
передачи ключа. Для решения данной проблемы применяется шифрование с от¬ 
крытым ключом [95]. Главное свойство этой системы заключается в том, что для 
шифрования и дешифрования используются различные ключи и что по заданно¬ 
му ключу шифрования определить соответствующий ключ дешифрации практи¬ 
чески невозможно. При таких условиях ключ шифрования может быть сделан от¬ 
крытым, и только ключ дешифрации будет храниться в секрете. 

Чтобы дать представление о шифровании с открытым ключом, рассмотрите две 
следующие задачи: 

Вопрос 1: Сколько будет 314159265358979 х 314159265358979? 

Вопрос 2: Чему равен квадратный корень из 3912571506419387090594828508241 ? 

Большинство шестиклассников, если дать им бумагу и карандаш, а также по¬ 
обещать действительно большое сливочное мороженое с сиропом за правильный 
ответ, смогут ответить на первый вопрос за один-два часа. Большинство взрослых 
людей, получив карандаш, бумагу и обещание пожизненного 50-процентного сни¬ 
жения налогов, не смогут вообще решить вторую задачу без помощи калькулятора, 
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компьютера или еще какой-нибудь внешней помощи. Хотя возведение в квадрат 
и извлечение квадратного корня представляют собой взаимообратные операции, 
их различие в сложности является огромным. Такой вид асимметрии и формиру¬ 
ет основу криптографии с открытым ключом. Для шифрования используется про¬ 
стая операция, но для дешифрации без ключа требуется выполнить огромный 
объем сложных вычислений. 

Система шифрования с открытым ключом К8А использует тот факт, что пере¬ 
множить два больших числа значительно легче, чем разложить большое число на 
множители, особенно когда используется модульная арифметика, а все большие 
числа состоят из сотен цифр [277]. Эта система широко используется в мире крип¬ 
тографии. Также применяются системы, основанные на дискретных логарифмах 
[106]. Главный недостаток систем шифрования с открытым ключом заключается 
в том, что они в тысячи раз медленнее, чем системы симметричного шифрования. 

Шифрование с открытым ключом используется следующим образом. Все уча¬ 
стники выбирают пару ключей (открытый ключ, закрытый ключ) и публикуют 
открытый ключ. Открытый ключ используется для шифрования, а закрытый — 
для дешифрации. Как правило, формирование ключей автоматизировано, иногда 
в качестве начального числа используется пароль, выбираемый пользователем. 
Чтобы отправить пользователю секретное сообщение, корреспондент зашифро¬ 
вывает его открытым ключом получателя. Поскольку закрытый ключ есть толь¬ 
ко у получателя, только он один сможет расшифровать сообщение. 

Необратимые функции 

Есть множество ситуаций, как мы увидим позднее, в которых требуется некая функ¬ 
ция /, обладающая тем свойством, что при заданной функции / и параметре х вы¬ 
числение у = /(х) легко выполнимо, но по заданному /(х) найти значение х невоз¬ 
можно по вычислениям. Такая функция, как правило, перемешивает биты сложным 
образом. Вначале она может присвоить числу у значение х. Затем в ней может рас¬ 
полагаться цикл, выполняющийся столько раз, сколько в числе х содержится еди¬ 
ничных битов. На каждом цикле биты числа у перемешиваются способом, завися¬ 
щим от номера цикла, плюс к числу у прибавляются определенные константы. 

Цифровые подписи 

Часто бывает необходимо подписать цифровой документ цифровой подписью. 
Например, предположим, клиент банка посылает банку по электронной почте со¬ 
общение с поручением купить для него определенные акции. Через час после того, 
как это сообщение было отправлено и поручение исполнено, биржа рушится. Теперь 
клиент отрицает, что он отправлял сообщение банку. Банк, естественно, воспро¬ 
изводит сообщение, но клиент заявляет, что банк его подделал. Как судье опреде¬ 
лить, кто говорит правду? 

С помощью цифровой подписи можно подписывать сообщения, посылаемые 
по электронной почте, и другие цифровые документы таким образом, чтобы от¬ 
правитель не смог потом отрицать, что посылал их. Один распространенный спо- 
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соб получения цифровой подписи заключается в том, что документ пропускается 
через необратимый алгоритм хэширования, который очень трудно инвертировать. 
Хэш-функция, как правило, формирует результат фиксированной длины, неза¬ 
висящей от изначальной длины документа. Наиболее популярными функциями 
хэширования являются ІѴГО5 (Мезза§е Бі^езі 5 — профиль сообщения 5), созда¬ 
ющий 16-байтовый результат [276], и алгоритм 8НА (Зесиге НазЬ А1§огііЬш — 
надежный алгоритм хэширования), формирующий 20-байтовый результат [248]. 

На следующем шаге предполагается использование криптографии с открытым 
ключом, как описывалось выше. Владелец документа с помощью своего закрыто¬ 
го ключа из хэша получает О(казк). Это значение, называемое сигнатурным бло¬ 
ком, добавляется к документу и посылается отправителю, как показано на рис. 9.2. 
Иногда применение функции О к хэш-коду называют дешифровкой хэша, но на 
самом деле эта операция не является дешифровкой, так как хэш-код не был зашиф¬ 
рован. Это просто математическое преобразование хэша. 



б 

Рис. 9.2. Вычисление сигнатурного блока (а); что получает получатель (б) 

Когда документ и хэш-код прибывают, получатель сначала с помощью алгорит¬ 
ма МЭ5 или 5НА (о выборе алгоритма отправитель и получатель договариваются 
заранее) вычисляет хэш-код документа. Затем получатель применяет к сигнатурно¬ 
му блоку алгоритм шифрования с открытым ключом, получая Е(0(казк)). В резуль¬ 
тате он зашифровывает «расшифрованный» хэш-код, снова получая оригинальное 
значение хэш-кода. Если вычисленный заново хэш-код не совпадает с расшифро¬ 
ванным сигнатурным блоком, это значит, что либо сообщение, либо сигнатурный 
блок были повреждены — или случайно, или преднамеренно. Смысл этой схемы 
в том, что медленное шифрование с открытым ключом применяется только для 
небольшого по размерам хэш-кода. Обратите внимание, что данный метод работа¬ 
ет только в том случае, если для всех х 

Е(0(х)) = х. 

Такое свойство не гарантировано априори для всех функций шифрования, так 
как все, что изначально требовалось, — это чтобы 

0(Е(х)) = х, 

то есть Е представляет собой функцию шифрования, а И — функцию дешифро¬ 
вания. Для возможности применения этих функций в цифровых подписях тре¬ 
буется, чтобы порядок применения функций не имел значения, то есть функции 
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Б и Е должны обладать свойством коммутативности 1 . К счастью, алгоритм К5А 
обладает таким свойством. 

Чтобы использовать схему электронной подписи, получатель должен знать от¬ 
крытый ключ отправителя. Некоторые пользователи публикуют свойства откры¬ 
тых ключей на своих \ѵеЬ-страницах. Другие этого не делают, так как опасаются, 
что злоумышленник может взломать страницу и незаметно подменить ключ. Для 
защиты от подобных действий требуется специальный механизм распределения 
открытых ключей. Один из широко применяемых методов заключается в том, что 
отправитель прикрепляет к сообщению сертификат, содержащий имя пользова¬ 
теля, и открытый ключ, подписанные ключом доверенной третьей стороны. Как 
только пользователь получит открытый ключ третьей стороны, он может получать 
сертификаты ото всех отправителей, использующих эту доверенную третью сто¬ 
рону для создания своих сертификатов. 

Выше было рассказано о применении шифрования с открытым ключом для 
цифровых подписей. Следует отметить, что также существуют схемы, не исполь¬ 
зующие шифрования с открытым ключом. 


Аутентификация пользователей 

Теперь, получив некоторое представление о криптографии, перейдем к рассмотре¬ 
нию вопросов безопасности в операционных системах. Когда пользователь регис¬ 
трируется на компьютере, операционная система, как правило, желает определить, 
кем является данный пользователь, и запускает процесс, называемый аутентифи¬ 
кацией пользователя. 

Аутентификация пользователя является одной из тех проблем, которые мы 
имели в виду, говоря, что «онтогенез повторяет филогенез» в соответствующем 
разделе главы 1. У первых мэйнфреймов, таких как Е№АС, не было операцион¬ 
ной системы, не говоря уже о процедуре регистрации. Более поздние пакетные 
системы и системы разделения времени уже, как правило, имели процедуры реги¬ 
страции для аутентификации заданий и пользователей. 

У первых мини-компьютеров (например, РБР-І и РОР-8) также не было про¬ 
цедуры регистрации, но с распространением операционной системы ІЖІХ на мини¬ 
компьютере РБР-11 такая процедура снова потребовалась. Первые персональные 
компьютеры (например, Арріе II и оригинальная версия ІВМ РС) не имели про¬ 
цедуры регистрации, но более сложным операционным системам для персональ¬ 
ных компьютеров, как, например, \Ѵіпс1о\ѵ5 2000, снова понадобилась процедура 
регистрации, обеспечивающая безопасность. Использование персонального компь¬ 
ютера для доступа к серверам на локальной сети или для входа на коммерческий 
\ѵеЬ-сайт всегда требует регистрации. Таким образом, проблема надежной регист¬ 
рации прошла несколько циклов и снова стала важной темой. 

1 Тем не менее для цифровых подписей можно использовать функции, и не обладающие подобной сим¬ 
метрией. Для этого нужно лишь создать новую пару ключей, из которых открытым сделать ключ де¬ 
шифрации, а ключ шифрования оставить закрытым. — Примеч. перев. 
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Итак, мы определили, что аутентификация часто бывает необходима. Теперь 
следует найти хороший метод ее достижения. Большинство методов аутентифи¬ 
кации пользователей основаны на распознавании: 

1) чего-то, известного пользователю; 

2) чего-то, имеющегося у пользователя; 

3) чего-то, чем является пользователь. 

На этих трех принципах построены три различные схемы аутентификации, об¬ 
ладающие различными сложностями и характеристиками безопасности. В следу¬ 
ющих разделах мы рассмотрим их все по очереди. 

Злоумышленнику, чтобы причинить ущерб какой-либо системе, необходимо 
сначала зарегистрироваться в ней. Это означает, что он должен преодолеть исполь¬ 
зуемую в данной системе процедуру аутентификации. В популярной прессе таких 
людей называют хакерами 1 . Однако в компьютерном мире слово «хакер» стало 
чем-то вроде почетного титула, закрепляемого за великими программистами. Та¬ 
ким образом, термин «хакер» стал двузначным. В прессе хакерами обычно назы¬ 
вают жуликов, однако далеко не все высококвалифицированные программисты 
являются мошенниками. Поэтому в данной книге, чтобы не путать эти два поня¬ 
тия, мы будем использовать для обозначения людей, вламывающихся в чужие ком¬ 
пьютерные системы, слово взломщик (сгаскег). 


Аутентификация с использованием паролей 

В наиболее широко применяемой форме аутентификации от пользователя требу¬ 
ется ввести имя и пароль. Защита пароля легко реализуется. Самый простой спо¬ 
соб реализации паролей заключается в поддержании централизованного списка 
пар (имя регистрации, пароль). Вводимое имя отыскивается в списке, а введен¬ 
ный пользователем пароль сравнивается с хранящимся в списке. Если пароли со¬ 
впадают, регистрация в системе разрешается, если нет — в регистрации пользова¬ 
телю отказывается. 

Как правило, при вводе пароля компьютер не должен отображать вводимые 
символы, чтобы находящиеся рядом посторонние люди не смогли узнать пароля. 
В операционной системе \Уіпс1о\ѵ5 2000 при вводе каждого символа отображается 
звездочка. В системе ІШІХ при этом вообще ничего не отображается. Эти схемы 
обладают различными свойствами. Схема, применяемая в \Уіпсіо\ѵ5 2000, помога¬ 
ет забывчивым пользователям, позволяя им видеть, сколько символов они уже 
набили. Однако это же свойство помогает злоумышленникам, сообщая им длину 
пароля. С точки зрения безопасности молчание является золотом. 

Другой пример из области вопроса о правильности реализации алгоритма регис¬ 
трации показан в листинге 9.1. В листинге 9.1, а показана успешная регистрация. 
Символы, вводимые пользователем, показаны как строчные, а символы, выводи¬ 
мые системой, — как прописные. В листинге 9.1, б изображена неудачная попытка 
взломщика войти в систему Л. В листинге 9.1, в показана неудачная попытка 
взломщика войти в систему В. 


1 Изначально это слово означало плохого игрока в гольф. — Примеч. перво. 
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Листинг 9.1 . Успешный вход в систему (а); в регистрации отказано после ввода 
имени (б); в регистрации отказано после ввода имени и пароля (в) 

ЮШ: кеп ЮШ: саго! 1_0Ш: саго! 

РА55ЮТ: ГооВаг ШѴАШ 1_0Ш МАМЕ РАЗБИТО: Ісіиппо 

БІІССЕББРІЛ ЦОСІМ ЮШ: ШАІ_Ю 1_0Ш 

ШШ: 

а б в 

В листинге 9.1, б система отказывает в регистрации сразу, как только видит 
неверное имя. Такое поведение алгоритма является ошибкой, так как облегчает 
взломщику задачу. В этом случае он может подобрать сначала имя, не зная пароля 
для него. В листинге 9.1, в у взломщика каждый раз спрашивается и имя, и пароль, 
и он не знает, почему ему было отказано в регистрации, то есть было ли неверно 
введено имя или пароль. Все, что ему известно, — это что данная комбинация имя 
плюс пароль неверна. 

Как взломщикам удается проникнуть в систему 

Большинство взломщиков проникают в систему, просто перебирая множество 
комбинаций имени и пароля, пока не находят комбинацию, которая работает. 
Многие пользователи используют в качестве регистрационного имени свое соб¬ 
ственное имя в той или иной форме. Например, для пользователя по имени ЕПеп 
Апп ЗтісЬ разумными кандидатами регистрационного имени являются еііеп, зпіііЬ, 

еііеп _ зтіТІі, еІІеп-зтііЬ, еІІеп.зтііЬ, езтііЬ, еазтііЬ и еаз. Вооружившись одной из 

книг типа 4096 имен для вашего новорожденного, плюс телефонной книгой, полной 
фамилий, взломщик без труда составит компьютеризированный список потенци¬ 
альных регистрационных имен, соответствующих стране, в которой он собирается 
произвести атаку (имя с11сп__зтііЬ может быть полезным в США или Великобри¬ 
тании, но вряд ли поможет в Японии). 

Конечно, угадать регистрационное имя — это еще не все. Также требуется 
подобрать пароль. Насколько это сложно? Проще, чем вы думаете. Классичес¬ 
кий труд по вопросу безопасности паролей был написан Моррисом и Томпсоном 
в 1979 году на основе исследований систем ІЛЧІХ [240]. Авторы данной книги 
скомпилировали список вероятных паролей: имя и фамилия, названия улиц, горо¬ 
дов, слова из словарей среднего размера (также слова, написанные задом напе¬ 
ред), автомобильные номера и короткие строки случайных символов. Затем они 
сравнили свой полученный таким образом список с системным файлом паролей, 
чтобы посмотреть, есть ли совпадения. Как выяснилось, более 86 % от общего ко¬ 
личества паролей в файле оказались в их списке. Аналогичный результат был по¬ 
лучен Кляйном в 1990 году [181]. 

Если кто-либо полагает, что пользователи с лучшей подготовкой пользуются 
паролями более высокого качества, то это неверно. Исследования паролей, прове¬ 
денные в финансовом районе Лондоне в 1997 году, показали, что 82 % паролей лег¬ 
ко отгадать. Среди часто используемых паролей были сексуальные термины, ру¬ 
гательства, имена людей (часто членов семьи или спортивных звезд), места отдыха 
и различные предметы, находящиеся в офисе [169]. Это означает, что взломщик 
без особого труда может получить список потенциальных регистрационных имен 
и список потенциальных паролей. 
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Так ли это существенно, что пароли легко отгадать? Да. В 1998 году газета 5ап 
/охе Мегсигу Ыетз сообщила, что житель городка Беркли Питер Шипли использо¬ 
вал несколько компьютеров в качестве устройств автодозвона. Эти компьютеры 
пытались дозвониться по всем 10 000 номерам одного коммутатора (например, 
(415) 770-хххх), перебирая номера в случайном порядке, чтобы обмануть телефон¬ 
ные компании, пытающиеся обнаружить подобное использование компьютеров. 
Произведя 2,6 млн звонков, он обнаружил 20 000 компьютеров в районе залива, 
200 из которых совсем не имели защиты. По оценке Питера Шипли, целеустрем¬ 
ленный взломщик смог бы преодолеть защиту у 75 % остальных компьютеров [88]. 

Комбинация системы автодозвона и алгоритма подбора паролей может быть 
смертельной. Австралийский взломщик написал программу, систематически пере¬ 
бирающую все номера телефонного коммутатора, а затем пытающуюся вломиться 
в систему методом подбора паролей и сообщающую ему об успехе. Среди множе¬ 
ства взломанных им систем был компьютер банка СіНЬапк в Саудовской Аравии, 
что позволило ему получить номера кредитных карт и сведения о кредитном лими¬ 
те (в одном случае $5 млн), а также записи транзакций (включая одно посещение 
публичного дома). Его коллега-взломщик также вломился в банк и собрал 4000 но¬ 
меров кредитных карт [88]. Когда подобная информация используется мошенни¬ 
ками, банк, как правило, яростно отрицает свою вину, перекладывая всю ответ¬ 
ственность на клиентов, которые, видимо, плохо хранили эту информацию. 

Альтернативой системе автодозвона является атака на компьютеры по Интер¬ 
нету. У каждого компьютера в Интернете есть 32-разрядный ІР-адрес, используе¬ 
мый для его идентификации. Люди обычно записывают эти адреса в виде четырех 
десятичных чисел в диапазоне от 0 до 255, разделенных точками. Взломщик легко 
может определить, есть ли у какого-либо компьютера некий ІР-адрес и работает 
ли данный компьютер в настоящий момент, при помощи команды 

ріпд ѵѵ.х.у.г 

Если компьютер с таким адресом включен, он ответит, и программа ріп§ сооб¬ 
щит время прохождения сигнала в оба конца в миллисекундах (хотя некоторые 
сайты теперь запрещают использование программы ріп§, чтобы предотвратить 
подобные атаки). Нетрудно написать программу, перебирающую различные ІР- 
адреса и подающую их на вход программе ріщ, аналогично тому, как перебирает 
номера телефонов обсуждавшаяся выше программа. Если по адресу т.х.у .2 обна¬ 
ружен включенный компьютер, взломщик может попытаться установить соедине¬ 
ние с помощью команды 

ГеІпеГ м.х.у .2 

Если попытка установки соединения принята (чего может и не быть, так как не 
все системные администраторы приветствуют случайную регистрацию по Интер¬ 
нету), взломщик может начать подбор регистрационных имен и паролей из спис¬ 
ка 1 . Далее методом проб и ошибок взломщик может, наконец, подобрать имя и па¬ 
роль, войти в систему и прочитать список паролей (расположенный в системах 
ІЖІХ в файле /еіс/раззтй, к которому часто разрешен доступ чтения для всех 


1 Кроме адреса компьютера, программе Іеіпеі следует еще дать на входе номер порта, который также 
предстоит найти перебором. — Примем, перев. 
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пользователей). После этого взломщик может начать собирать статистику о частоте 
использования имен и паролей для оптимизации дальнейших поисков. 

Многие демоны Іеіпеі разрывают ТСР-соединение после некоторого числа не¬ 
удачных попыток регистрации, чтобы затормозить процесс подбора пароля взлом¬ 
щиком. Взломщики отвечают на этот прием установкой множества параллельных 
потоков, работающих одновременно с различными компьютерами. Их цель за¬ 
ключается в том, чтобы выполнять столько попыток подбора пароля в секунду, 
сколько позволит пропускная способность линии связи. С их точки зрения вынуж¬ 
денное распыление сил по многим машинам не является серьезным недостатком. 

Вместо того чтобы перебирать машины командой ріщ по порядку их ІР-адре- 
сов, взломщик может поставить себе целью вломиться на компьютер какой-либо 
конкретной компании, университета или другой организации. Например, его ин¬ 
тересует университет вымышленного города Фубар с БЫЗ-адресом / ооЪаг.есІи . 
Чтобы определить ІР-адреса, используемые этим университетом, все, что ему надо 
сделать, — это ввести команду 

сіпздиегу ТооЬаг. есіи 

и он получит список некоторых ІР-адресов университета. (С той же целью может 
использоваться программа пзіоокир или программа сіі%.) Поскольку многие орга¬ 
низации владеют 65 536 последовательными ІР-адресами (распространенная в про¬ 
шлом выделяемая область адресного пространства), узнав от программы йтциегу 
первые 2 байта ІР-адреса, взломщик получает сразу информацию обо всех 65 536 
адресах данной организации. Затем он может перебирать эти адреса программой 
ріщ, чтобы определить, какой из этих компьютеров отзывается, и попытаться ус¬ 
тановить с ним ТСР-соединение программой іеіпеі. Затем остается лишь подобрать 
имя и пароль, что мы уже обсуждали выше. 

Вся последовательность действий — определение первых двух байтов ІР-адре¬ 
са по имени домена, перебор этих адресов программой ріщ, проверка на установ¬ 
ку іеіпеі-с оединений, а затем перебор статистически вероятных пар имени и паро¬ 
ля — представляет собой процесс, который легко автоматизируется. Потребуется 
очень много попыток, чтобы взломать защиту, но если компьютеры в чем-то хоро¬ 
ши, так это в способности без устали повторять одну и ту же последовательность 
операций. Взломщике высокоскоростным кабелем или ИЗЬ-соединением (Бі§ка1 
ЗиЬзсгіЬег Ілпе — цифровая абонентская линия) может запрограммировать про¬ 
цесс на работу в течение всего дня и просто периодически проверять, как идут дела. 

Атака через Интернет, очевидно, существенно выгоднее для взломщика, чем 
автодозвон, так как перебор происходит значительно быстрее (не требуется время 
на дозванивание), а также существенно дешевле (не требуется плата за между¬ 
городние телефонные звонки). Но такой метод годится только для машин, под¬ 
ключенных к Интернету и принимающих Ге/иеГ-соединения. Тем не менее многие 
компании (и почти все университеты) принимают Ге/яеі-соединения, чтобы со¬ 
трудники, находящиеся в командировках или в отдаленном офисе (или студенты 
из своих домов), могли получить удаленный доступ в систему. 

Не только пароли пользователей часто бывают легко подбираемыми, но такое 
часто случается и с системными (корневыми) паролями. В частности, на многих 
системах после их установки не меняют пароли по умолчанию, с которыми постав- 
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ляется система. Клифф Столл, астроном из университета Беркли, заметил какие- 
то неполадки в своей системе, после чего установил ловушку против взломщика, 
пытавшегося проникнуть в систему [317]. Он зарегистрировал сеанс связи зло¬ 
умышленника, уже вломившегося на одну машину лаборатории Ьа\ѵгепсе Вегкіеу 
(ЬВЬ) и пытавшегося проникнуть еще на одну, показанный в листинге 9.1. Учет¬ 
ная запись ииср (ІЖІХ Іо ІЖІХ Сору Рго§гат — протокол, используемый для 
обмена между согласованными ІЖІХ-системами) используется для межмашинно¬ 
го сетевого трафика и обладает полномочиями суперпользователя, поэтому взлом¬ 
щик был на машине Министерства энергетики США в качестве суперпользовате¬ 
ля. К счастью, лаборатория Ьа\ѵгепсе Вегкіеу не занимается разработкой ядерного 
оружия, в отличие от родственной ей лаборатории в Ливерморе. Некоторые орга¬ 
низации полагают, что их защита лучше, но для такого мнения находится мало 
оснований, с тех пор как в 2000 году еще одна лаборатория ядерного оружия в Лос- 
Аламосе потеряла свой жесткий диск, полный секретной информации. 

Листинг 9.2. Протокол сеанса связи взломщика, проникшего на компьютер 
Министерства энергетики США в лаборатории І_а\л/гѳпсѳ Вегкіеу 

ЦВБ> Реі пеР еіхзі 
ЕІХ5І АТ І.ВІ. 

ЮШ: гооі 
РА55И0К0: гооі 

ІМССМЕСТ РАЗЗкШО, ТКУ АВА^ 

ЮШ: дие$Т 

РА55ЮТ: диезТ 

ІЫСОККЕСТ РА551ЙМ), ТКУ АСАІ N1 

ЮШ: ииср 

РА55ЮТ: ииср 

МЕІХОМЕ ТО ТНЕ ЕІ.Х5І С0МР1ЯЕК АТ І.ВІ. 

Вломившись в систему и став суперпользователем, взломщик может устано¬ 
вить сетевой анализатор пакетов, программу, изучающую все входящие и исхо¬ 
дящие пакеты и пытающуюся найти в них определенные последовательности дан¬ 
ных. Особый интерес для поиска представляют люди, регистрирующиеся с этой 
скомпрометированной машины на удаленных машинах, особенно с полномочия¬ 
ми суперпользователя на этих удаленных машинах. Эта информация может соби¬ 
раться для взломщика в файл, который он позднее заберет. Таким образом, взлом¬ 
щик, проникнув на машину со слабой защитой, часто может использовать это как 
средство для проникновения на другие машины с более серьезной защитой. 

Последнее время все больше взломов защиты осуществляется технически 
безграмотными пользователями, которые просто запускают сценарии, найден¬ 
ные в Интернете. Эти сценарии либо применяют атаку по описанному выше мето¬ 
ду грубой силы, либо используют известные ошибки в определенных программах. 
Настоящие хакеры называют таких взломщиков зсгірі кісісііез (детишки со сцена¬ 
риями). 

Как правило, у таких «детишек» нет конкретной цели или установки на похи¬ 
щение определенной информации. Они просто ищут машины, на которые легко 
вломиться. Некоторые используемые ими сценарии даже используют случайные 
сетевые адреса (старшая часть ІР-адреса), после чего перебирают все машины в этой 
случайной сети, ища компьютер, который ответит на запрос. Когда набирается база 
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данных работающих ІР-адресов, сценарий начинает атаку каждого компьютера по 
очереди. В результате может оказаться, что только что установленный секретный 
военный компьютер может быть атакован уже через несколько часов после под¬ 
ключения к Интернету, хотя никто, кроме администратора, еще не знает об этом 
компьютере. 

Защита паролей в системе ІШІХ 

В некоторых (старых) операционных системах файл паролей хранился на диске в 
незашифрованном виде, но защищался стандартными системными механизмами 
защиты. Хранить все пароли на диске в незашифрованном виде означает самому 
искать неприятности, так как многие люди слишком часто будут иметь доступ к 
нему. Это системные администраторы, операторы, обслуживающий персонал, про¬ 
граммисты, руководители и, возможно, даже секретарши. 

Лучшее решение выглядит следующим образом. Программа регистрации про¬ 
сит пользователя ввести свое имя и пароль. Пароль немедленно используется в ка¬ 
честве ключа для шифрации определенного блока данных. То есть выполняется 
необратимая функция, на вход которой подается пароль. Затем программа ре¬ 
гистрации считывает файл паролей, представляющий собой последовательность 
АЗСП-строк, по одной на пользователя, и находит в нем строку, содержащую имя 
пользователя. Если (зашифрованный) пароль, содержащийся в этой строке, совпа¬ 
дает с только что вычисленным зашифрованным паролем, регистрация разрешает¬ 
ся, в противном случае в регистрации пользователю отказывается. Преимущество 
этой схемы состоит в том, что никто, даже суперпользователь, не может просмот¬ 
реть пароли пользователей, поскольку нигде в системе они не хранятся в отрытом виде. 

Однако такая схема также может быть атакована следующим образом. Взлом¬ 
щик сначала создает словарь, состоящий из вероятных паролей, как это делали 
Моррис и Томпсон. Затем они зашифровываются с помощью известного алгорит¬ 
ма. Не важно, сколько времени занимает данный процесс, так как все это выпол¬ 
няется заблаговременно. Затем, вооружившись списком пар (пароль, зашифрован¬ 
ный пароль), взломщик наносит удар. Он считывает (доступный для всех) файл 
паролей и сравнивает хранящиеся в нем зашифрованные пароли с содержимым 
своего списка. Каждое совпадение означает, что взломщику стали известны имя 
регистрации и соответствующий ему пароль. Этот процесс может быть автомати¬ 
зирован простым сценарием оболочки. При запуске такого сценария, как правило, 
можно определить сразу несколько десятков паролей. 

Осознав возможность такой атаки, Моррис и Томпсон разработали метод, дела¬ 
ющий данный способ взлома практически бесполезным. Их идея заключается в том, 
что с каждым паролем связывается псевдослучайное число, состоящее из п битов, 
названное ими «солью». При каждой смене пароля это число также меняется. Это 
случайное число хранится в файле в незашифрованном виде, так что все могут его 
читать. В файле паролей хранится не зашифрованный пароль, а зашифрованная 
вместе пара пароля и случайного числа. Фрагмент файла паролей показан в табл. 9.2. 
Для каждого из пяти пользователей в файле отведена одна строка с полями, разде¬ 
ленными запятыми: имя регистрации, «соль», зашифрованная пара пароль + соль. 
Нотация е{Бо§4238) означает конкатенацию пароля пользователя ВоЬЬіе Бо§ со 
случайным числом 4238, результат которой был зашифрован функцией е. 
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Таблица 9.2. Применение случайного числа для защиты от попытки взлома 
с помощью заранее сосчитанных зашифрованных паролей 

ВоЬЬІе, 4238, е(Оод4238) 

Топу, 2918, е(6%%ТаеРР2918) 

І_аига, 6902, е(56аке5реаге6902) 

Магк, 1694, е(ХаВ@Вѵѵс2І694) 

ОеЬогаИ, 1092, е(1_огсіВугоп,1092) 


Посмотрим теперь, как такой вариант хранения паролей повлияет на описан¬ 
ный выше метод взлома, при котором злоумышленник составлял список вероят¬ 
ных паролей, зашифровывал их и сохранял в отсортированном файле/, чтобы ус¬ 
корить поиск пароля. Теперь, если взломщик предполагает, что Бо§ может быть 
паролем, ему уже недостаточно зашифровать Бо§ и поместить результат в файл /. 
Теперь ему придется зашифровать уже 2" строк, таких как 0о&0000, Бо§0001, 
Бо%0002 и т. д„ и поместить все эти варианты в файл /. В системе ІШІХ данный 
метод применяется с п — 12, поэтому размер файла/увеличивается в 2 12 раз. 

Для повышения надежности в некоторых современных версиях системы ІЖІХ 
доступ чтения к самому файлу паролей напрямую запрещен, а для регистрации 
предоставляется специальная программа, просматривающая содержимое этого 
файла по запросу и устанавливающая задержку между запросами, чтобы суще¬ 
ственно снизить скорость подбора паролей при любом методе. Такая комбинация 
добавления «соли» к паролям, запрета непосредственного чтения файла паролей 
и замедления доступа к файлу через специальную процедуру может противосто¬ 
ять многим вариантам методов взлома системы. 

Совершенствование безопасности паролей 

Добавление случайных чисел к файлу паролей защищает систему от взломщиков, 
пытающихся заранее составить большой список зашифрованных паролей, и таким 
образом взломать несколько паролей сразу. Однако данный метод бессилен помочь 
в том случае, когда пароль легко отгадать, например если пользователь БаѵШ ис¬ 
пользует пароль БаѵШ. Взломщик может просто попытаться отгадать пароли один 
за другим. Обучение пользователей в данной области может помочь, но оно редко 
проводится. Помимо обучения пользователей может использоваться помощь 
компьютера. На некоторых системах устанавливается программа, формирующая 
случайные, легко произносимые бессмысленные слова, такие как /оіаііу, §агЬип@у 
или Ыріііу, которые могут использоваться в качестве паролей (желательно с исполь¬ 
зованием прописных символов и специальных символов, добавленных внутрь). 
Программа, вызываемая пользователем для установки или смены пароля, может 
также выдать предупреждение при выборе слабого пароля. Среди требований про¬ 
граммы к паролю могут быть, например, следующие: 

1. Пароль должен содержать как минимум семь символов. 

2. Пароль должен содержать как строчные, так и прописные символы. 

3. Пароль должен содержать как минимум одну цифру или специальный символ. 

4. Пароль не должен представлять собой слово, содержащееся в словаре, имя 
собственное и т. д. 
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Снисходительная программа может просто брюзжать, строгая программа мо¬ 
жет отвергать пароль и требовать ввода лучшего варианта. Программа установки 
пароля может также предложить свой вариант, как уже обсуждалось выше. 

Некоторые операционные системы требуют от пользователей регулярной сме¬ 
ны паролей, чтобы ограничить ущерб от утечки пароля. Недостаток такой схемы 
в том, что если пользователи должны слишком часто менять свои пароли, они 
достаточно быстро устают придумывать и запоминать хорошие пароли и пере¬ 
ходят к простым паролям. Если система запрещает выбирать простые пароли, 
пользователи забывают сложные пароли и начинают записывать их на листках 
бумаги, приклеиваемых к мониторам, что становится главной дырой в защите. 

Одноразовые пароли 

Предельный вариант частой смены паролей представляет собой использование 
одноразовых паролей. При использовании одноразовых паролей пользователь 
получает блокнот, содержащий список паролей, Для каждого входа в систему ис¬ 
пользуется следующий пароль в списке. Если взломщику и удастся узнать уже 
использованный пароль, он ему не пригодится, так как каждый раз используется 
новый пароль. Предполагается, что пользователь постарается не терять блокнот 
с паролями. 

В действительности без такого блокнота можно обойтись, если применить эле¬ 
гантную схему, разработанную Лесли Лампортом, гарантирующую пользователю 
безопасную регистрацию в небезопасной сети при использовании одноразовых 
паролей [191]. Метод Лампорта может применяться для того, чтобы позволить 
пользователю с домашнего персонального компьютера регистрироваться на сер¬ 
вере по Интернету, даже в том случае, если злоумышленники смогут просматри¬ 
вать и копировать весь его поток в обоих направлениях. Более того, никаких сек¬ 
ретов не нужно хранить ни на домашнем персональном компьютере, ни на сервере. 

Алгоритм основан на необратимой функции, то есть функции у = /(х), обла¬ 
дающей тем свойством, что по заданному х легко найти у, но по заданному у 
подобрать х невозможно по вычислениям. Вход и выход должны иметь одинако¬ 
вую длину, например 128 битов. 

Пользователь выбирает секретный пароль, который он запоминает. Затем он 
также выбирает целое число п, означающее количество одноразовых паролей, фор¬ 
мируемое алгоритмом. Для примера рассмотрим п = 4, хотя на практике использу¬ 
ются гораздо большие значения. Пусть секретный пароль равен 5. Тогда первый 
пароль получается в результате выполнения необратимой функции/(х) п раз (то 
есть четыре раза): 

Л = /(/(/(/( 5 ))))- 

Второй пароль получается, если применить необратимую функцию /(х) п - 1 раз 
(то есть три раза): 

Р2=/(/(/Ш- 

Для получения третьего пароля нужно выполнить функцию/ (х) два раза, а для 
четвертого — один раз. Таким образом, Р,_,=/ (Р,). Основной момент, на кото¬ 
рый следует обратить здесь внимание, заключается в том, что при использовании 
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данного метода легко вычислить предыдущий пароль, но почти невозможно опре¬ 
делить следующий. Например, по данному Р 2 легко найти Р ь но невозможно 
определить Р 3 . 

Сервер инициализируется числом Р 0 , представляющим собой просто/ (ДД. Это 
значение хранится в файле паролей, вместе с именем пользователя и целым чис¬ 
лом 1, указывающим, что следующий пароль равен/(РД. Когда пользователь пы¬ 
тается зарегистрироваться на сервере в первый раз, он посылает на сервер свое 
регистрационное имя, в ответ на которое сервер высылает целое число 1, храня¬ 
щееся в файле паролей. Машина пользователя отвечает числом Р и вычисляемым 
локально из $, вводимого пользователем. Затем сервер вычисляет/ (РД и сравни¬ 
вает результат с хранящимся в файле паролей значением Р 0 . Если эти значения 
совпадают, регистрация разрешается, целое число увеличивается на единицу, а Рі 
записывается в файл поверх Р 0 . 

При следующем входе в систему сервер посылает пользователю число 2, а ма¬ 
шина пользователя вычисляет Р 2 . Затем сервер вычисляет/ (РД и сравнивает его 
с хранящимся в файле значением. Если эти значения совпадают, регистрация раз¬ 
решается, целое число увеличивается на единицу, а Р 2 записывается в файл паро¬ 
лей поверх Рі. И если злоумышленнику удастся узнать Рі, у него нет способа полу¬ 
чить из него Р ж , а только Р м , то есть уже использованное и теперь бесполезное 
значение. Когда все п паролей использованы, сервер реинициализируется новым 
секретным ключом. 

Схема аутентификации «оклик-отзыв» 

Еще один вариант идеи паролей заключается в том, что для каждого нового 
пользователя создается длинный список вопросов и ответов, который хранится на 
сервере в надежном виде (например, в зашифрованном виде). Вопросы должны 
выбираться так, чтобы пользователю не нужно было их записывать. Примеры воз¬ 
можных вопросов: 

1. Как зовут сестру Марджолин? 

2. На какой улице была ваша начальная школа? 

3. Что преподавала миссис Воробофф? 

При регистрации сервер задает один из этих вопросов, выбирая его из списка 
случайным образом, и проверяет ответ. Однако чтобы такая схема могла работать, 
потребуется большое количество пар вопросов и ответов. 

Другой вариант называется «оклик-отзыв». Он работает следующим образом. 
Пользователь выбирает алгоритм, идентифицирующий его как пользователя, напри¬ 
мер х 2 . Когда пользователь входит в систему, сервер посылает ему некое случайное 
число, например 7. В ответ пользователь посылает серверу 49. Алгоритм может от¬ 
личаться утром и вечером, в различные дни недели и т. д. 

Если терминал пользователя обладает достаточной вычислительной мощнос¬ 
тью, как, например, персональный компьютер, персональный цифровой помощник 
или сотовый телефон, возможно использование более мощной формы схемы «ок¬ 
лик-отзыв». Пользователь заранее выбирает секретный ключ к, который вручную 
заносится на сервер. Копия этого ключа (в зашифрованном виде) хранится на 
компьютере пользователя. При регистрации сервер посылает пользователю случай- 
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ное число г. Компьютер пользователя вычисляет и отсылает обратно значение 
/ (г, к), где /—не являющаяся секретной функция. Сервер, в свою очередь, также 
производит те же вычисления и сравнивает полученный результат с присланным 
пользователем значением. Преимущество такой схемы перед обычным паролем 
заключается в том, что если злоумышленник даже запишет весь трафик в обоих 
направлениях, он не сможет получить информацию, которая поможет ему в следу¬ 
ющий раз. Конечно, функция /должна быть достаточно сложной, чтобы даже при 
большом количестве наблюдений злоумышленник не смог вычислить значение к. 

Аутентификация с использованием 
физического объекта 

Второй метод аутентификации пользователей заключается в проверке некоторо¬ 
го физического объекта, который есть у пользователя, а не информации, которую 
он знает. Например, в течение столетий применялись металлические дверные клю¬ 
чи. Сегодня этим физическим объектом часто является пластиковая карта, вставля¬ 
емая в специальное устройство чтения, подключенное к терминалу или компью¬ 
теру. Как правило, пользователь должен не только вставить карту, но также ввести 
пароль, чтобы предотвратить использование потерянной или украденной карты. 
С этой точки зрения использование банкомата (АТМ, АиІотаГіс Теііег МасЫпе) 
начинается с того, что пользователь регистрируется на компьютере банка с удален¬ 
ного терминала (банкомата) при помощи пластиковой карты и пароля. Сегодня 
в большинстве стран применяется РІЫ-код (РШ, Регзопаі Ібепіійсаііоп ЫишЬег — 
личный идентификационный номер), состоящий всего из 4 цифр, что позволяет 
избежать необходимости установки полной клавиатуры на банкоматы. 

Существует две разновидности пластиковых карт, хранящих информацию: маг¬ 
нитные карты и карты с процессором. Магнитные карты содержат около 140 байт 
информации, записанной на магнитной ленте, приклеенной к пластику. Эта инфор¬ 
мация может быть считана терминалом и передана на центральный компьютер. Час¬ 
то эти данные содержат пароль пользователя (например, его РШ-код), так что 
терминал может сам проверить подлинность пользователя без помощи головно¬ 
го компьютера. Как правило, пароль шифруется ключом, известным только банку. 
Эти карты стоят от 10 до 50 центов, в зависимости от наличия голограммы и тира¬ 
жа. Применять магнитные карты для идентификации рискованно, так как устрой¬ 
ства чтения и записи этих карт дешевы и широко распространены. 

Карты, содержащие в себе микросхемы, в свою очередь, подразделяются на две 
категории: карты, хранящие информацию, и смарт-карты (зтаіТ сагсі — «умная» 
карта). Карты, хранящие информацию, содержат небольшое количество памяти 
(как правило, менее 1 Кбайт), использующей технологию ЕЕРКОМ (ЕІесСгісаІІу 
ЕгазаЫе Рго§гатшаЫе Кеаб-Опіу Метогу — электрически стираемое программи¬ 
руемое ПЗУ). На такой карте нет центрального процессора, поэтому сохраняемое 
значение должно изменяться внешним центральным процессором (в считывающем 
устройстве). Такие карты производятся миллионами по цене около одного доллара 
за штуку и широко применяются, например, в качестве телефонных карт, деньги 
за которые заплачены заранее. При звонке телефон просто уменьшает на единицу 
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значение в карте, но деньги при этом из рук в руки не переходят. По этой причине 
такие карты в основном выпускаются одной компанией для использования толь¬ 
ко на их машинах (скажем, телефонах или торговых автоматах). Их можно исполь¬ 
зовать для аутентификации пользователя при регистрации и хранить на них па¬ 
роль размером в 1 Кбайт, который посылается на удаленный компьютер, но это 
редко делается. 

Однако сегодня большой объем работ в сфере безопасности проводится со 
смарт-картами. На данный момент они обладают, как правило, 8-разрядным цен¬ 
тральным процессором, работающим с тактовой частотой 4 МГц, 16 Кбайт ПЗУ, 
4 Кбайт ЕЕРКОМ, 512 байт временной оперативной памяти и каналом связи со 
скоростью 9600 бит/с для обмена данными с устройством чтения. Со временем эти 
«умные» карты становятся все «умнее», но они ограничены по многим парамет¬ 
рам, включая толщину микросхемы (так как она должна быть встроена в карту), 
ширину микросхемы (чтобы избежать ее поломки, когда пользователь сгибает кар¬ 
ту) и стоимость (обычно от 5 до 50 долларов, в зависимости от мощности цент¬ 
рального процессора, размеров памяти и наличия или отсутствия специального 
криптографического сопроцессора). 

Смарт-карты могут использоваться для хранения денег, как и карты, хранящие 
данные, но по сравнению с этим видом карт смарт-карты обладают значительно 
лучшими характеристиками в плане безопасности и универсальности. Эти карты 
можно зарядить деньгами в банкомате или дома по телефону с помощью специ¬ 
ального устройства, поставляемого банком. Позднее, например, в магазине, пользо¬ 
ватель может разрешить снять с карты определенную денежную сумму (напеча¬ 
тав УЕ5), в результате чего карта посылает небольшое шифрованное сообщение 
продавцу. Затем продавец может передать это сообщение в банк, чтобы получить 
указанную в нем сумму. 

Большое преимущество смарт-карт перед кредитными и дебетными картами 
состоит в том, что для использования смарт-карт не требуется соединения с банком 
в режиме оп-1іпе. Если вы не верите, что данное свойство является преимуществом, 
попытайтесь произвести следующий эксперимент. Попробуйте купить всего одну 
конфету в магазине и настоять на ее оплате кредитной картой. Если продавец воз¬ 
ражает, скажите, что у вас нет с собой наличных денег, кроме того, вы стараетесь 
чаще расплачиваться картой, чтобы получить различные бонусы и скидки. Вы заме¬ 
тите, что продавец не в восторге от этой идеи (поскольку затраты, связанные с уста¬ 
новкой соединения с банком, практически съедят всю прибыль). Смарт-карты 
оказываются удобными для мелких покупок, платы за телефонные разговоры, пар¬ 
ковку автомобиля, расчетов с торговыми автоматами и многими другими устрой¬ 
ствами, которые обычно требуют монетку. Такие устройства широко распростра¬ 
нены в Европе и становятся все популярнее в других местах. 

У смарт-карт есть много других возможных применений (хранение в надежно 
закодированном виде сведений о состоянии здоровья владельца, например данных 
об аллергии на определенные лекарства и т. п.), но нас сейчас интересует другое. 
Вопрос в том, как можно использовать смарт-карты для безопасной регистрации. 
Основная концепция проста: смарт-карта представляет собой маленький, защи¬ 
щенный от подделок компьютер, способный вступить в диалог (называемый про¬ 
токолом) с центральным компьютером для аутентификации пользователя. Так, 
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пользователь, желающий приобрести товары на коммерческом \ѵеЪ-сайте, может 
вставить смарт-карту в домашний адаптер, соединенный с персональным компь¬ 
ютером. Это обеспечит не только более надежную аутентификацию пользователя, 
но также позволит \ѵеЬ-сайту сразу же вычесть нужную сумму из смарт-карты, что 
позволит избежать основных накладных расходов (и риска), связанных с исполь¬ 
зованием кредитной карты при покупках в режиме оп-1іпе. 

Со смарт-картами могут применяться различные схемы аутентификации. 
Простой протокол «оклик-отзыв» работает следующим образом. Сервер посыла¬ 
ет 512-разрядное случайное число смарт-карте, которая добавляет к нему 512-раз- 
рядный пароль, хранящийся в электрически стираемом программируемом ПЗУ. 
Затем сумма возводится в квадрат, и средние 512 бит посылаются обратно на сер¬ 
вер, которому известен пароль пользователя, поэтому сервер может произвести те 
же операции и проверить правильность результата. Эта последовательность пока¬ 
зана на рис. 9.3. Если даже злоумышленник видит оба сообщения, он не может оп¬ 
ределить по ним пароль. Сохранять эти сообщения также нет смысла для взлом¬ 
щика, так как в следующий раз сервер пошлет пользователю другое 512-разрядное 
случайное число. Конечно, вместо возведения в квадрат может применяться (и, как 
правило, применяется) более хитрый алгоритм. 


Удаленный 



Рис. 9.3. Использование смарт-карты для аутентификации 

Недостаток любого фиксированного криптографического протокола состоит 
в том, что со временем он может быть взломан, в результате чего смарт-карта ста¬ 
нет бесполезной. Избежать этого можно, если хранить в памяти карты не сам крип¬ 
тографический протокол, а интерпретатор ^ѵа. При этом настоящий криптогра¬ 
фический протокол будет загружаться в карту в виде двоичной программы }аѵа и 
исполняться на ней. Таким образом, как только один протокол взломан, можно 
мгновенно перейти на использование другого протокола. Недостаток такого под¬ 
хода заключается в том, что и без того не отличающаяся высокой производитель¬ 
ностью смарт-карта будет работать еще медленнее, однако с развитием техноло¬ 
гий этот метод приобретает все большую гибкость. Другой недостаток смарт-карт 
состоит в том, что потеря или кража карты может привести к раскрытию ключа 
при помощи анализа энергопотребления карты. Эксперт, обладающий соответ¬ 
ствующим оборудованием, наблюдая за потребляемой картой электрической мощ- 
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ностью во время выполнения ею повторяемых операций шифрования, может оп¬ 
ределить ключ. Измерения времени, требуемого на зашифровку различных спе¬ 
циально подобранных ключей, также могут дать достаточно сведений для опреде¬ 
ления секретного ключа. 

Аутентификация с использованием 
биометрических данных 

Третий метод аутентификации основан на измерении физических характеристик 
пользователя, которые трудно подделать. Они называются биометрическими па¬ 
раметрами [258]. Например, для идентификации пользователя может использо¬ 
ваться специальное устройство считывания отпечатков пальцев или тембра голоса. 

Работа типичной биометрической системы состоит из двух этапов: внесение 
пользователя в список и идентификация. Во время первого этапа характеристики 
пользователя измеряются и оцифровываются. Затем извлекаются существенные 
особенности, которые сохраняются в записи, ассоциированной с пользователем. 
Эта запись может храниться на компьютере в централизованной базе данных (на¬ 
пример, для регистрации в системе с удаленного компьютера) или в смарт-карте, 
которую пользователь носит с собой и вставляет в устройство чтения смарт-карт 
(например, банкомата). 

Второй этап процесса представляет собой идентификацию. Пользователь вво¬ 
дит регистрационное имя. Затем система снова производит замеры. Если новые 
значения совпадают с хранящимися в записи, регистрация разрешается, в против¬ 
ном случае в регистрации пользователю отказывается. Ввод имени при регистра¬ 
ции нужен, так как измерения не точны, поэтому их сложно использовать в каче¬ 
стве индекса для поиска. Кроме того, два человека могут обладать очень близкими 
характеристиками, поэтому требование соответствия этих параметров для одного 
определенного пользователя является значительно более строгим требованием, 
чем простое совпадение с характеристиками любого пользователя. 

Измеряемые характеристики должны отличаться у различных пользователей 
в достаточно широких пределах, чтобы система могла безошибочно различать разных 
людей. Например, цвет волос не является хорошим индикатором, так как у очень 
многих людей волосы одного и того же цвета. Кроме того, эти характеристики не 
должны сильно изменяться со временем. Например, голос человека может изменять¬ 
ся вследствие простуды, а лицо может выглядеть по-другому благодаря наличию или 
отсутствию бороды или макияжа во время начальных замеров. Поскольку последу¬ 
ющие измерения никогда точно не совпадут с первоначальными, разработчики та¬ 
кой системы должны решить, насколько точным должно быть сходство. В частно¬ 
сти, им придется решить, что лучше — отказать пару раз законному пользователю 
или время от времени разрешать вход в систему жулику. Коммерческий сайт мо¬ 
жет решить, что лучше терпеть небольшие убытки от мошенников, чем отказывать 
в регистрации постоянным клиентам, тогда как сервер лаборатории ядерного ору¬ 
жия может решить, что лучше иногда отказать в регистрации настоящему сотруд¬ 
нику, чем позволить пару раз в год войти в систему случайному чужаку. 

Теперь рассмотрим некоторые биометрические показатели, использующиеся на 
сегодняшний день. На удивление часто на практике используется измерение дли- 
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ны пальцев. При этом каждый терминал оснащается устройством вроде показан¬ 
ного на рис. 9.4. Пользователь засовывает в него руку, и устройство измеряет дли¬ 
ну его пальцев и сравнивается с информацией, хранящейся в базе данных. 



Рис. 9.4. Устройство для измерения длины пальцев 


Однако измерение длины пальцев обладает существенным недостатком. Эту 
систему легко обмануть, подсунув ей гипсовый (или из другого материала) сле¬ 
пок, возможно даже с настраиваемой длиной выдвижных пальцев, чтобы иметь 
возможность подбирать требуемые размеры. 

Последнее время все большую популярность приобретают измерения рисунка 
сетчатки глаз. У каждого человека неповторимый рисунок кровеносных сосудов 
на сетчатке, даже у идентичных близнецов. Сетчатка глаза может быть аккуратно 
сфотографирована камерой с расстояния в один метр, возможно даже без ведома 
фотографируемого пользователя. Сетчатка глаза содержит значительно больше 
информации, чем отпечаток пальца. Эти данные можно закодировать, например, 
256 байтами. 

Подобную технику можно попытаться обмануть. Например, мошенник может 
подойти к банкомату, надев темные очки, к которым приклеены фотографии чу¬ 
жой сетчатки. В конце концов, если камера банкомата способна получить хорошую 
по качеству фотографию сетчатки глаза с расстояния в один метр, то кто-либо дру¬ 
гой также сможет это сделать, и даже с больших расстояний, используя телеобъек¬ 
тив. По этой причине вместо фотокамер обычно используются видеокамеры, фик¬ 
сирующие пульсацию, присутствующую в кровеносных сосудах сетчатки глаза. 

Другой метод идентификации заключается в анализе подписи. Пользователь 
ставит подпись специальным пером, соединенным с терминалом, и компьютер све¬ 
ряет ее с оригиналом, хранящимся на удаленном сервере или в смарт-карте. Лучше 
всего сравнивать не саму подпись, а движения пера и давление пера на бумагу. 
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Хороший специалист по подделке подписей может нарисовать довольно точную 
копию подписи, но он может не суметь угадать, в каком порядке выполняются движе¬ 
ния, а также в точности повторить рисунок скорости, ускорений и давления пера. 

Для измерения характеристик голоса требуется минимум специальной аппа¬ 
ратуры [224]. Все, что для этого нужно, — это микрофон (возможно, даже телефон); 
все остальное выполняется программно. В отличие от систем распознавания речи, 
пытающихся определить, что говорит пользователь, эти системы пытаются опре¬ 
делить, кем является говорящий. В некоторых системах пользователь должен про¬ 
сто произнести скрытый пароль, но такие системы легко обманываются злоумыш¬ 
ленниками, записывающими разговор на магнитофон и воспроизводящими его 
позднее. Более сложные системы говорят пользователю определенную фразу и 
просят повторить именно ее, причем при каждой регистрации используется новый 
текст. Некоторые компании начинают применять распознавание голоса в различ¬ 
ных приложениях, таких как заказы товаров по телефону, так как подделать голос 
значительно сложнее, чем РШ-код. 

Подобные примеры биометрических параметров можно продолжать еще и еще, 
но два примера помогут сделать важное замечание. Кошки и другие животные мо¬ 
чой метят периметр своих владений. Очевидно, кошки могут идентифицировать 
друг друга подобным образом. Представьте себе, что кому-нибудь удастся создать 
небольшое устройство, способное производить мгновенный анализ мочи, обеспечи¬ 
вая, таким образом, надежную идентификацию. Каждый терминал можно будет 
снабдить подобным устройством, снабдив терминал надписью: «Для регистрации 
помочитесь сюда, пожалуйста». Возможно, таким образом удалось бы создать 
абсолютно надежную систему, хотя она вряд ли понравилась бы пользователям. 

То же самое можно сказать о системе, состоящей из иголки и небольшого спек¬ 
трографа. Пользователю предлагается проколоть палец иголкой, предоставив 
таким образом каплю крови для спектрографического анализа. Дело в том, что 
любая схема аутентификации должна быть психологически приемлема для сооб¬ 
щества пользователей. Измерение длины пальцев, возможно, не вызовет проблем, 
но даже такая безобидная процедура, как снятие отпечатков пальцев, может ока¬ 
заться неприемлемой, так как у многих это действие ассоциируется с обвинением 
в преступлении. 

Контрмеры 

В некоторых компьютерных системах, серьезно относящихся к вопросу безопасно¬ 
сти (отношение к этому вопросу, как правило, кардинально меняется на следующий 
день после того, как злоумышленник вломился в систему и причинил серьезный 
ущерб), часто предпринимаются шаги, призванные усложнить несанкционирован¬ 
ный вход в систему. Так, компания может установить политику, разрешающую 
регистрацию сотрудников патентного отдела только с 8 часов утра до 5 вечера 
с понедельника по пятницу и только с машины, находящейся в патентном отделе. 
Любая попытка сотрудника патентного отдела зарегистрироваться в другие часы 
или не с того компьютера будет расцениваться как попытка взлома системы. 

Телефонные коммутируемые линии также можно сделать более безопасными. 
Например, всем разрешается регистрироваться в системе через модем по телефон- 
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ной линии, но после успешной регистрации система немедленно прерывает соеди¬ 
нение и сама звонит пользователю по заранее условленному номеру. Такая мера 
означает, что взломщик не может вломиться в систему с любой телефонной ли¬ 
нии. Для работы в системе подойдут только линии зарегистрированных пользова¬ 
телей. В любом случае, с применением данной техники или без нее, система долж¬ 
на обязательно выдерживать паузу по крайней мере в 5 с при проверке пароля 
и увеличивать этот временной интервал после каждой неуспешной попытки реги¬ 
страции, чтоб снизить частоту попыток взломщика. После трех неуспешных по¬ 
пыток регистрации линия должна отключаться на 10 мин, а персонал уведомлять¬ 
ся о попытке несанкционированного входа в систему. 

Все попытки входа в систему должны регистрироваться. Когда пользователь 
регистрируется, система должна сообщать ему дату и время последней регистра¬ 
ции, а также терминал, с которого производилась эта регистрация, чтобы пользо¬ 
ватель мог заметить взлом системы злоумышленником. 

Еще один вариант защиты может заключаться в установке ловушки для взлом¬ 
щика. Простая схема ловушки представляет собой специальное имя регистрации 
с простым паролем (например, имя §иезІ и пароль §иезІ). При каждом входе в сис¬ 
тему с таким именем системные специалисты в области безопасности немедленно 
уведомляются. Все команды, вводимые взломщиком, немедленно отображаются 
на мониторе руководителя службы безопасности, чтобы он мог видеть, что наме¬ 
ревается сделать взломщик. 

Другие ловушки могут представлять собой легко обнаруживаемые ошибки в опе¬ 
рационной системе и тому подобные вещи, намеренно разработанные с целью от¬ 
лавливания злоумышленников на месте преступления. В 1989 году Столл написал 
занимательный доклад о ловушках, установленных им с целью поймать шпиона, 
вломившегося на университетский компьютер в поисках военных секретов [317]. 


Атаки изнутри системы 

Зарегистрировавшись на компьютере, взломщик может начать причинение ущер¬ 
ба. Если на компьютере установлена надежная система безопасности, возможно, 
взломщик сможет навредить только тому пользователю, чей пароль он взломал, 
но часто начальная регистрация может использоваться в качестве ступеньки для 
последующего взлома других учетных записей. В следующих разделах будут рас¬ 
смотрены разновидности атак со стороны уже зарегистрировавшегося в системе 
пользователя, либо взломщика, либо законного пользователя со злым умыслом 
против кого-либо. 


Троянские кони 

Одним из давно известных вариантов атаки изнутри является троянский конь, 
представляющий собой невинную с виду программу, содержащую процедуру, вы¬ 
полняющую неожиданные и нежелательные функции. Этими функциями могут 
быть удаление или шифрование файлов пользователя, копирование их туда, где 
их впоследствии может получить взломщик, или даже отсылка их взломщику или 
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во временное укромное место по электронной почте или с помощью протокола 
РТР. Чтобы троянский конь заработал, нужно, чтобы программа, содержащая его, 
была запущена. Один способ состоит в бесплатном распространении такой про¬ 
граммы через Интернет под видом новой игры, проигрывателя МРЗ, «специаль¬ 
ной» программы для просмотра порнографии и т. д., лишь бы привлечь внимание 
и поощрить загрузку программы. При запуске программы вызывается процедура 
троянского коня, которая может выполнять любые действия в пределах полномо¬ 
чий запустившего ее пользователя (например, удалять файлы, устанавливать се¬ 
тевые соединения и т. д.). Обратите внимание, что тактика применения троянско¬ 
го коня позволяет обойтись без взлома компьютера жертвы. 

Существуют также другие приемы, заставляющие жертву запустить троянско¬ 
го коня. Например, многие пользователи системы ІЖІХ используют системную 
переменную окружения $РАТН, управляющую каталогами, в которых система 
ищет введенную команду. Ее значение можно просмотреть следующей командой 
оболочки: 

есйо $РАТН 

Например, возможное значение этой переменной для пользователя азі может 
состоять из следующих каталогов: 

: /изг/азЕ/Ьіп:/изг/іосаі /Ып:/и$г/Ып:/Ып: /изг/Ып/ХІІ :/изг/исЬ:/и5г/шап\ 
.7и$г/)аѵа/Ьіп.7и5г/)аѵа/1 іЬ: /изг/1 осаі /тал: /изг/орепѵ^іп/тап 

У других пользователей могут быть установлены другие пути поиска. Когда 
пользователь вводит в оболочке команду 

ргод 

оболочка сначала ищет программу /изг/азі/Ьіп/рго§. Если такого файла нет, обо¬ 
лочка пытается найти файлы /изг/ІосаІ/Ып/рпщ, /изг/Ып/рго§, /Ып/рго§ и т. д., 
перебирая поочередно все 10 каталогов, содержащихся в строке $РАТН. Предпо¬ 
ложим, что один из этих каталогов не был защищен, что позволило взломщику 
поместить туда программу. Если система, перебирая список каталогов, наткнется 
на эту программу, она запустится и троянский конь заработает. 

Большая часть часто используемых программ хранится в каталогах /Ып или 
/изг/Ып, поэтому, если поместить троянского коня в файл /изг/Ьіп/ХІІ/Із, то ни¬ 
чего не получится, так как настоящая программа будет найдена первой. Однако 
предположим, что взломщик поместит в каталог /изг/Ып/Х11 программу Іа. Если 
пользователь ошибочно введет Іа вместо 1з (программы, печатающей листинг ка¬ 
талога), то троянский конь запустится, сделает свое грязное дело, после чего вы¬ 
ведет сообщение, что файл Іа не найден. Таким образом, помещая троянских ко¬ 
ней в каталоги, в которые практически никто никогда не заглядывает под именами 
распространенных ошибок ввода с клавиатуры, злоумышленник может рассчиты¬ 
вать, что рано или поздно его уловка сработает'. И случайно запустить троянского 
коня может даже суперпользователь (даже суперпользователи иногда ошибаются 
при вводе команд). В этом случае троянский конь получает возможность заменить 
программу /Ып /Із своей версией, также содержащей троянского коня, который 
теперь будет запускаться при каждом обращении к программе Із. 
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Злоумышленник (назовем его Мэл), являющийся законным пользователем, 
может установить ловушку суперпользователю и следующим образом. Он может 
поместить свою версию программы Із в своем каталоге (скажем, таі), а затем сде¬ 
лать что-либо подозрительное, что наверняка привлечет внимание суперполь¬ 
зователя, например запустит одновременно 100 процессов, ограниченных про¬ 
изводительностью процессора. Есть шанс, что суперпользователь проверит, что 
происходит, и введет следующую последовательность команд: 

Ы /изг/шаі 

1 5 -1 

чтобы посмотреть, что хранится в каталоге Мэла. Поскольку некоторые оболочки 
сначала ищут вызываемую программу в текущем каталоге, а уже затем в каталогах, 
перечисленных в строке $РАТН, суперпользователь, таким образом, вызовет троян¬ 
ского коня Мэла, наделив его на время запуска полномочиями суперпользовате¬ 
ля. При этом троянский конь может, например, сделать программу /изг/таІ/Ып/ 
зк корневой с полномочиями суперпользователя. Для этого требуются всего два 
системных вызова: сіюип, чтобы сменить владельца файла /изг/таІ/Ып/зк на гооі, 
и сИшосІ, чтобы установить ее 5ЕТ11ГО бит. Теперь Мэл может становиться супер¬ 
пользователем, когда ему вздумается, просто запуская свой вариант оболочки. 

Если Мэл часто оказывается не при деньгах, он может применить одну из следу¬ 
ющих махинаций с троянским конем, чтобы поправить свое финансовое положение. 
Первый вариант заключается в том, что троянский конь проверяет, установлена 
ли у жертвы банковская программа, например (2 иіскеп, работающая в режиме оп- 
Ііпе. Если да, то троянский конь велит этой программе перевести определенную 
сумму со счета жертвы на некий подставной счет (желательно в далекой стране), 
чтобы забрать их оттуда позднее. 

Вторая жульническая схема состоит в том, что троянский конь сначала выклю¬ 
чает звук модема, после чего звонит по платному телефонному номеру, начинаю¬ 
щемуся с цифр 900, опять же, предпочтительно, в далекую страну, например Мол¬ 
дову (бывшую советскую республику). Если пользователь находился в режиме 
оп-1іпе во время запуска троянского коня, тогда телефонный номер в Молдове дол¬ 
жен быть (очень дорогим) Интернет-провайдером, так что пользователь, вероят¬ 
но, не заметит этого и останется в режиме оп-1іпе в течение нескольких часов. Оба 
приведенных варианта не являются гипотетическими. Об обоих методах мошенни¬ 
чества сообщалось в [88]. В последнем случае общее время телефонной связи с Мол¬ 
довой составило 800 000 мин, прежде чем Федеральной торговой комиссии США 
удалось выйти на след и завести судебное дело против трех человек на Лонг-Айлен¬ 
де. В конечном итоге они согласились вернуть 38 000 жертвам 2,74 млн долларов. 

Фальшивая программа регистрации 

В чем-то схожа с троянскими конями жульническая схема с фальшивой регистра¬ 
цией. Эта схема работает следующим образом. Обычно при регистрации в системе 
ІЖІХ на терминале или рабочей станции, подключенной к локальной сети, пользо¬ 
ватель видит экран, показанный на рис. 9.5, а. Когда пользователь садится за тер¬ 
минал и вводит свое регистрационное имя, система спрашивает у него пароль. Если 
пароль верен, пользователю разрешается вход в систему и оболочка запускается. 
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б 

Рис. 9.5. Настоящий экран регистрации (а); фальшивый экран регистрации (б) 

Теперь рассмотрим следующий сценарий. Мэл пишет программу, изображаю¬ 
щую экран, показанный на рис. 9.5, б. Она выглядит в точности как настоящее окно, 
предлагающее пользователю зарегистрироваться. Теперь Мэл отходит в сторонку 
и наблюдает за происходящим с безопасного расстояния. Когда пользователь садит¬ 
ся за терминал и набирает имя, программа в ответ запрашивает пароль и отключает 
эхо. Когда имя и пароль получены, они записываются в файл, после чего фальши¬ 
вая программа регистрации посылает сигнал уничтожения собственной оболочки. 
В результате этого действия сеанс работы Мэла на этом терминале завершается 
и запускается настоящая процедура регистрации. Пользователь при этом полага¬ 
ет, что он неверно ввел пароль и просто регистрируется еще раз. На этот раз все 
проходит успешно. Но Мэлу таким образом удается получить имя и пароль. Заре¬ 
гистрировавшись на нескольких терминалах и запустив на них свою обманываю¬ 
щую пользователей программу, он может за один день собрать много паролей. 

Единственный способ защиты от подобной атаки заключается в том, чтобы про¬ 
грамма регистрации запускалась по комбинации клавиш, которую не может пере¬ 
хватить программа пользователя. В системе \ѴіпсІо\ѵз 2000 для этой цели исполь¬ 
зуется комбинация клавиш СТК1.+А1.Т+0Е1-. Если пользователь садится за терминал 
и начинает с того, что нажимает на клавиатуре СТКІл-АП+ОЕІ-, то сеанс работы теку¬ 
щего пользователя в системе завершается 1 и запускается системная программа 
регистрации. Обмануть этот механизм невозможно. 



Логические бомбы 

Сегодня, когда мобильность наемных работников значительно увеличилась, по¬ 
явилась еще одна разновидность атаки системы изнутри, называемая логической 
бомбой. Логическая бомба представляет собой программу, написанную одним из 
сотрудников компании и тайно установленную в операционную систему. До тех 
пор пока программист каждый день входит в систему под своим именем и паролем, 
эта программа не предпринимает никаких действий. Однако если программиста 
внезапно увольняют и физически удаляют из помещения без предупреждения, то 
на следующий день (или на следующую неделю) логическая бомба, не получив 
своего ежедневного пароля, начинает действовать. Существует множество вариа¬ 
ций на эту тему. В одном знаменитом случае программа проверяла платежную ве¬ 
домость. Если личный номер программиста не появлялся в двух последователь¬ 
ных ведомостях подряд, бомба взрывалась [310]. 

1 Точнее, в системе ХѴіпсІочѵя 2000 нажатие этой комбинации клавиш, когда в системе уже зарегистрирован 
какой-либо пользователь, вызовет появление на экране окна менеджера системы. — Примеч. перев. 
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Взрыв логической бомбы может заключаться в форматировании жесткого дис¬ 
ка, удалении файлов в случайном порядке, осуществлении сложно обнаруживае¬ 
мых изменений в ключевых программах или шифровании важных файлов. В по¬ 
следнем случае компания оказывается перед сложным выбором: вызвать полицию 
(в результате чего много месяцев спустя злоумышленника, возможно, арестуют 
и признают виновным, но файлы уже не будут восстановлены) или сдаться шан¬ 
тажисту и снова нанять на работу этого программиста в качестве «консультанта» 
с астрономическим окладом для восстановления системы (и надеяться, что он при 
этом не заложит новые логические бомбы). 


Потайные двери 

Еще один способ создания дыры в системе безопасности изнутри называется по¬ 
тайной дверью. Для этого в систему системным программистом внедряется спе¬ 
циальная программа, позволяющая обойти нормальную процедуру проверки. На¬ 
пример, программист может добавить к программе регистрации кусок программы, 
пропускающий в систему пользователя с именем « 22222 », независимо от того, что 
содержится в файле паролей. Нормальный цикл процедуры регистрации может 
выглядеть так, как показано в листинге 9.3, а. В листинге 9.3, б показана изменен¬ 
ная программа после установки в нее потайного входа. Процедура зігсшр исполь¬ 
зуется для сравнения имени регистрации со строкой « 22222 ». Если пользователь 
ввел при регистрации это имя, то пароль уже не важен. Если такой потайной лаз 
установлен программистом, работающим на фирме, производящей компьютеры, 
а затем поставляется вместе с компьютерами, впоследствии этот программист смо¬ 
жет зарегистрироваться на любом компьютере, произведенном его компанией, 
независимо от того, кому будет принадлежать компьютер и какая информация 
будет содержаться в файле паролей. Потайная дверь просто обходит весь процесс 
аутентификации. 


Листинг 9.3. Нормальная программа (а); программа с установленной 
потайной дверью (б) 


Огііе спад { 

ргіпШ"1одіп: "): 
деІ_5Сппд(пате) ; 
сіі заЫ е_есНоі пд( ); 
ргіпЩ"ра55МЭГСІ: "): 
деІ_5Ігіпд(раз5шгс1); 
епаЫе_есЬоіпд( ): 
ѵ = сІзеск_ѵа1 ісіі Ту ( пате , раззшгсі): 
іС (ѵ) Ьгеак; 

} 

ехесиІе_5Ье11 (пате) : 


мміе спад { 

ргіпШ"1одіп: "): 

деІ_5Ігіпд(пате); 
сіізаЫе_есІпоіпд( ): 
ргіпЩ"ра55ШГСІ: "): 
деС_5Ігіпд(ра55мэгс1); 
епаЫе_есЬоіпд( ): 
ѵ = сЬеск_ѵа) і сіі Ту ( пате . раззмэгсі); 
ѵГ (ѵ || 5Ігстр(пате, " 22222 ") == 0) Ьгеак 
} 

ехесиГе зЬеШпате); 


а б 

Чтобы не допустить установки потайных дверей в систему, компании могут, 
например, ввести регулярные просмотры программ. При этом, когда программист 
закончил писать и тестировать программный модуль, модуль проверяется и поме¬ 
щается в базу данных. Периодически все программисты команды собираются вме¬ 
сте и каждый из них поочередно разъясняет остальным, что делает его программа, 
строка за строкой. При этом вероятность обнаружения потайных дверей значи- 
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тельно увеличивается. Кроме того, если программиста поймают за подобным за¬ 
нятием, то это не будет плюсом в его карьере. Если программисты слишком резко 
возражают против такой процедуры, можно поручить программистам проверку 
программ друг друга. 


Переполнение буфера 

В основе множества атак лежит тот факт, что практически все операционные сис¬ 
темы написаны на языке программирования С (так как программисты любят этот 
язык, а также потому, что программы на языке С компилируются крайне эффек¬ 
тивно). К сожалению, ни один компилятор языка С не выполняет проверки гра¬ 
ниц массива. Соответственно, следующий кусок программы представляется ком¬ 
пилятору вполне законным: 

іпЕ і : 

сНаг с[1024]: 
і = 12000: 
с[і] = 0: 

В результате выполнения этого куска программы некий байт в памяти, находя¬ 
щийся на 10 976 байт за пределами массива с, будет обнулен, возможно, с катаст¬ 
рофическими последствиями. Во время исполнения программы не производится 
никакой проверки, чтобы предотвратить эту ошибку. 

Это свойство языка С позволяет произвести атаку следующего типа. На рис. 9.6, а 
показана работающая головная программа со своими локальными переменными в 
стеке. В некоторый момент она вызывает процедуру А, как показано на рис. 9.6, б. 
Стандартная процедура вызова начинается с того, что в стек помещается адрес 
возврата (указывающий на команду, следующую за вызовом). Затем управление 
передается процедуре А, которая помещает в стек свои локальные переменные. 


Виртуальное Виртуальное Виртуальное 

адресное адресное адресное 

пространство пространство пространство 



а б в 


Рис. 9.6. Работает головная программа (а); вызывается процедура А (б); 
переполнение буфера показано серым цветом (в) 
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Предположим, что для работы процедуре А требуется получить полный путь 
к файлу (возможно, при помощи объединения пути текущего каталога с именем 
файла), после чего открыть этот файл и выполнить с ним какие-либо действия. 
У процедуры А есть буфер В фиксированного размера (то есть массив), в котором 
она содержит имя файла (рис. 9.6, б ). Использовать буфер фиксированного размера 
значительно проще, чем сначала вычислить требуемый размер, а затем динамичес¬ 
ки запросить у системы буфер нужного размера. Если зарезервировать буфер дли¬ 
ной 1024 байт, то его должно быть достаточно для хранения любых имен файлов, 
не так ли? Особенно если операционная система ограничивает дину имен файлов 
(или, что еще лучше, длину полного пути) 255 символами. 

К сожалению, в данных рассуждениях содержится фатальный просчет. Пред¬ 
положим, что пользователь задает этой программе имя файла длиной в 2000 сим¬ 
волов. При этом программа не сможет открыть файл, но взломщика это не волну¬ 
ет. Когда процедура скопирует имя файла в свой буфер, имя файла переполнит 
буфер и затрет область памяти, показанную серым цветом на рис. 9.6, в. Что еще 
хуже, если имя файла достаточно длинное, оно также запишется поверх адреса 
возврата, поэтому, когда процедура А станет выполнять возврат в головной модуль, 
адрес возврата процедура А возьмет из середины имени файла. Если этот адрес 
представляет собой случайный мусор, то программа прыгнет по случайному адре¬ 
су и, вероятно, аварийно завершится, выполнив несколько команд. 

Но что, если содержимое имени файла не случайно? Что, если оно содержит 
работоспособную программу и тщательно настроено, так чтобы адрес возврата как 
раз указывал на начало этой программы, например на начало буфера В? При этом 
после возврата из процедуры А начнет выполняться программа в буфере В. Таким 
образом, взломщику удалось внедрить в программу свою процедуру и передать ей 
управление. 

Тот же самый трюк может сработать с любой длинной строкой, превышающей 
размер зарезервированного под нее буфера. Этой строкой может быть, например, 
строка переменных окружения, пользовательский ввод и т. д. Предоставляя про¬ 
грамме длинную, заранее подготовленную строку, содержащую программу, можно 
попасть этой программой на стек и, таким образом, добиться ее выполнения. Биб¬ 
лиотечная функция §еСз языка С, читающая строку неизвестного размера в буфер 
фиксированной длины, печально известна подверженности атакам подобного рода. 
Некоторые компиляторы даже распознают использование функции §еСз и предуп¬ 
реждают об этом. 

Теперь мы подходим к самой серьезной части этой истории. Предположим, что 
в системе ІШІХ атакуется программа с установленным битом ЗЕТІІГО, владель¬ 
цем которой является гооі (или программа, обладающая полномочиями систем¬ 
ного администратора в )Уіпсіо\Ѵ5 2000, что примерно то же самое). Вставленный 
участок программы может при помощи пары системных вызовов дать полномо¬ 
чия суперпользователя файлу оболочки взломщика на диске. Альтернативные ва¬ 
рианты заключаются в использовании специально приготовленной общей библио¬ 
теки, способной причинить разнообразный ущерб, или запуска оболочки вместо 
текущей программы при помощи системного вызова ехес, в результате чего пользо¬ 
ватель окажется в оболочке с полномочиями суперпользователя. Значительный 
процент всех проблем безопасности связан с подобным дефектом программ, не 
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проверяющих длину данных, копируемых в буфер фиксированной длины. Испра¬ 
вить все программы достаточно сложно, так как системных программ, написанных 
на языке С и не проверяющих переполнения буфера, очень много. 

Обнаружить программу, не имеющую проверки переполнения буфера, очень 
легко: достаточно дать ей на входе имя файла из 10 000 символов, денежную 
сумму в 100 цифр или что-либо подобное и посмотреть, не сломается ли она с вы¬ 
дачей распечатки области памяти. Затем нужно проанализировать образ памяти 
и определить, где располагается данная длинная строка. После этого определить, 
в каком месте и какие символы следует указать, чтобы перехватить управление, 
переписав адрес возврата, не так уж сложно. Если к тому же доступен исходный 
код программы, как это имеет место для большинства программ в системе ІЖІХ, 
подобная атака еще более упрощается, так как содержимое стека известно заранее. 
Защита от атак подобного рода заключается в явной проверке длины всех поставля¬ 
емых пользователем строк перед копированием этих строк в буферы. К сожале¬ 
нию, подверженность какой-либо программы подобной атаке, как правило, выяс¬ 
няется уже после успешной атаки. 


Атака системы безопасности 

Обычный способ проверить надежность системы безопасности состоит в пригла¬ 
шении группы экспертов, называемых командой тигров, или группой проникно¬ 
вения, чтобы посмотреть, смогут ли они взломать защиту. Иногда в качестве та¬ 
кой команды приглашались аспиранты [151]. За несколько лет подобные команды 
обнаружили множество областей, в которых операционные системы проявляют 
свою слабость. Ниже будут перечислены наиболее распространенные методы атак, 
часто завершающиеся успехом. Хотя изначально эти методы разрабатывались для 
атаки систем разделения времени, они часто могут применяться и для нападения 
на серверы локальных сетей и другие совместно используемые машины. При разра¬ 
ботке таких систем убедитесь, что они могут выдержать атаки следующих типов: 

1. Запросите страницы памяти, место на диске или магнитной ленте и просто 
считайте. Многие системы не очищают память при ее выделении пользова¬ 
телю, поэтому память и диски могут содержать много интересной информа¬ 
ции, записанной предыдущим владельцем. 

2. Попытайтесь обратиться к несуществующим системным вызовам или к име¬ 
ющимся системным вызовам, но с неверными параметрами, например не 
того типа или слишком большой длины. Многие системы не выдерживают 
подобных атак. 

3. Начните регистрацию, а затем нажмите клавишу ЙЕЦ КІІВ01ІТ или ВКЕАК по¬ 
среди процесса регистрации. В некоторых системах подобным образом уда¬ 
ется уничтожить процесс, осуществляющий проверку пароля, и регистра¬ 
ция считается успешной. 

4. Попытайтесь модифицировать сложные структуры операционной системы, 
хранящиеся в памяти пользователя (если таковые имеются). В некоторых 
системах (особенно на мэйнфреймах) для того, чтобы открыть файл, про¬ 
грамма формирует большую структуру, содержащую имя файла и множе- 
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ство других параметров, которую передает операционной системе. При 
чтении и записи файла операционная система иногда сама обновляет эту 
структуру. Модификация некоторых полей может иметь разрушительное 
воздействие на безопасность. 

5. Прочитайте руководство и попытайтесь найти фразы, гласящие: «Не делай¬ 
те X». Попытайтесь проделать X в различных комбинациях. 

6. Убедите системного администратора добавить потайную дверь с обходом 
важных этапов проверки безопасности для любого пользователя с вашим 
именем. 

7. Если ничего не сработает, попытайтесь найти секретаршу системного адми¬ 
нистратора и притвориться несчастным пользователем, забывшим свой па¬ 
роль. В качестве альтернативы можно попытаться подкупить секретаршу. 
У секретарши, как правило, есть доступ к самой разнообразной и очень ин¬ 
тересной информации, а зарплата обычно невелика. Не следует недооцени¬ 
вать человеческий фактор. 

Подобные и другие методы атак обсуждаются в [210]. Хотя эта статья вышла 
уже более четверти века тому назад, многие методы, описанные в ней, все еще ра¬ 
ботают. 

Печально знаменитые дефекты 
системы безопасности 

Как в области транспорта есть свои Титанит , Конкорды и Гинденбурги, у раз¬ 
работчиков операционных систем также есть множество вещей, о которых они 
предпочли бы забыть. В данном разделе мы рассмотрим некоторые интересные 
проблемы в области систем безопасности, имевшие место в трех операционных 
системах: ШІХ, ТЕИЕХ и 05/360. 

Знаменитые дефекты системы безопасности ІІЫІХ 

У утилиты Ірг системы ІЖІХ, печатающей файл на принтере, есть входной пара¬ 
метр, позволяющий удалять печатаемый файл после вывода на принтер. В ранних 
версиях системы ІЖІХ любой пользователь мог распечатать и удалить с помощью 
этой утилиты файл паролей. 

Другой способ взлома системы ІЖІХ заключался в установке связи с файлом 
паролей файла с именем соге, находящимся в рабочем каталоге пользователя. За¬ 
тем взломщик намеренно вызывал сбой с сохранением образа памяти 5ЕТІІШ- 
программы, который система записывала в файл соге, то есть поверх файла паро¬ 
лей. Таким образом, пользователь мог заменить содержимое файла паролей, указав 
в новом файле несколько строк по собственному усмотрению (задавая их в каче¬ 
стве аргументов команды). 

Еще один метод взлома защиты системы ІЖІХ включал использование команды 
тксііг Гоо 

Утилита тМіг была 5ЕТІІШ-программой, владельцем которой являлась систе¬ 
ма (гоо!). Эта программа создавала і-узел для каталога/оо при помощи системно- 
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го вызова шкпосі, после чего изменяла владельца каталога /оо со своего идентифи¬ 
катора ШО (то есть гооі) на ШО пользователя. Когда система была медленной, 
пользователю иногда удавалось успеть быстро удалить і-узел каталога и создать 
связь с файлом паролей под именем /оо после системного вызова шкпосі, но до сис¬ 
темного вызова сЬомп. Когда утилита тЫггвыполняла системный вызов сЬоып, она 
делала пользователя владельцем файла паролей. Поместив необходимые коман¬ 
ды в файл сценария оболочки, взломщик мог пытаться выполнить эту операцию 
снова и снова, пока трюк не срабатывал. 

Знаменитые дефекты системы безопасности ТЕЫЕХ 

Операционная система ТЕЫЕХ была очень популярна на машинах ОЕС-10. Теперь 
она уже не используется, но эта система навечно останется в анналах по компьютер¬ 
ной безопасности благодаря следующей ошибке разработчиков. Система ТЕЫЕХ 
поддерживала страничную организацию памяти. Чтобы пользователи могли от¬ 
слеживать поведение собственных программ, можно было запрограммировать 
систему на вызов функции пользователя при каждом страничном прерывании. 

Для защиты файлов в системе ТЕЫЕХ также использовались пароли. Для по¬ 
лучения доступа к файлу программа должна была указать операционной системе 
правильный пароль во время открытия файла. Операционная система проверяла 
пароль символ за символом, останавливаясь, как только видела, что пароль неверен. 
Чтобы взломать защиту системы ТЕЫЕХ, злоумышленник мог аккуратно располо¬ 
жить пароль в памяти так, как указано на рис. 9.7, а, поместив первый символ паро¬ 
ля в конце одной страницы, а остальные символы — в начале следующей страницы. 
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Рис. 9.7. Взлом пароля в системе ТЕЫЕХ 

Затем необходимо гарантировать отсутствие в памяти второй страницы, для 
чего можно, например, много раз обратиться к другим страницам. После этого про¬ 
грамма пыталась открыть файл жертвы с помощью тщательно подбираемого паро¬ 
ля. Если первый символ пароля угадан пользователем неверно, система остановит 
проверку на первом же символе, ответив соответствующим сообщением, и стра¬ 
ничного прерывания не произойдет. Если же первый символ верен, операционная 
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система перейдет к проверке следующего символа, вызывая страничное прерыва¬ 
ние, отслеживаемое программой пользователя. 

Таким образом, программа может перебирать символ за символом, отгадывая 
пароль буква за буквой и сдвигая пароль при каждом отгаданном символе на один 
символ вниз относительно границы страниц (рис. 9.7, в). Для нахождения всего 
пароля требуется перебор менее 128 символов (набор А5СІІ) для каждой позиции 
в пароле. Следовательно, для нахождения пароля длиной в п символов требуется 
всего 128 п попыток вместо 128". 

Знаменитые дефекты системы безопасности 08/360 

Теперь рассмотрим дефекты безопасности в системе 08/360. Описание слегка 
упрощено, но в нем сохранена суть проблемы. В данной системе можно было запу¬ 
стить чтение магнитной ленты, а затем продолжить вычисления во время считы¬ 
вания данных с ленты в пространство пользователя. Трюк заключался в том, чтобы 
начать чтение ленты, а затем обратиться к системному вызову, которому требова¬ 
лась структура данных пользователя, например файл и его пароль. 

Операционная система сначала проверяла верность пароля для данного файла. 
После этого она возвращалась и считывала имя этого файла снова уже для его чте¬ 
ния. (Это имя могло бы храниться в системе, но этого не делалось.) К сожалению, 
как раз перед тем, как операционная система собиралась считать имя файла во вто¬ 
рой раз, поверх этого имени считывалось новое имя с магнитной ленты. Таким 
образом, операционная система, проверив правильность пароля для одного фай¬ 
ла, считывала другой файл, для которого у пользователя пароля не было. Чтобы 
точно рассчитать время обращений к системным вызовам, требовалась определен¬ 
ная практика, но это было не так уж сложно. 

Принципы проектирования систем безопасности 

Теперь читателю должно быть ясно, что разработка хорошо защищенной опера¬ 
ционной системы представляет собой нетривиальную задачу. Над этой проблемой 
без особого успеха билось множество людей. В 1975 году исследователи опреде¬ 
лили несколько общих принципов, которые необходимо использовать при проек¬ 
тировании надежных систем [287]. Ниже приведен краткий обзор некоторых из 
этих идей (основанных на опыте работы в системе МШЛТС8). Значимость этих 
идей за последние четверть века не изменилась. 

Во-первых, устройство системы не должно быть секретом. Предположение, что 
взломщики не знают, как работает система, может только ввести разработчиков 
в заблуждение. Рано или поздно взломщики узнают нужную им информацию, 
и если защита системы окажется скомпрометированной этой утечкой информа¬ 
ции, это значит, что такая система безопасности ни на что не годится. 

Во-вторых, по умолчанию доступ не должен предоставляться. Об ошибках, 
в результате которых пользователям было отказано в законном доступе, сообщат 
значительно быстрее, чем о случаях ошибочного предоставления несанкциониро¬ 
ванного доступа. Когда есть сомнение, говорите «Нет». 

В-третьих, необходимо проверять текущее состояние прав доступа. Система не 
должна, проверив наличие прав доступа и убедившись, что доступ разрешен, затем 
сохранять эту информацию для последующего использования. Многие системы 
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проверяют разрешение доступа при открытии файла, но не после этого. Это означа¬ 
ет, что пользователь, открывший файл и держащий его открытым неделями, будет 
продолжать обладать доступом к файлу, даже если владелец файла с тех пор уже 
давно изменил защиту файла или, может, даже пытался удалить этот файл. 

В-четвертых, предоставляйте каждому процессу как можно меньше привиле¬ 
гий. Если у редактора есть доступ только к редактируемому файлу (указанный при 
вызове редактора), редакторы, представляющие собой троянских коней с ахейца¬ 
ми в брюхе, не смогут причинить большого вреда. Применение этого принципа 
предполагает схему защиты высокой степени детализации. Подобные схемы будут 
рассматриваться позднее в этой главе. 

В-пятых, механизм защиты должен быть простым, одинаковым для всех и встро¬ 
енным в самые нижние уровни системы. Попытка установить систему безопаснос¬ 
ти на существующую незащищенную систему практически невыполнима. Безопас¬ 
ность, как и корректность, не является свойством, которое можно добавить потом. 

В-шестых, выбранная схема должна быть психологически приемлемой. Если 
пользователи почувствуют, что для защиты файлов требуется затратить слишком 
много усилий, они не станут этого делать. Тем не менее они будут громко жало¬ 
ваться, если что-либо пойдет не так. Ответы типа «это ваша вина», как правило, не 
будут восприниматься с пониманием. 

К этому списку нам хотелось бы добавить еще один принцип, выработанный 
в результате десятилетий трудного опыта: 

Сохраняйте схему простой. 

Если система элегантна и проста, была создана одним разработчиком и имеет 
несколько основополагающих принципов, определяющих все остальное, то есть 
шанс, что она будет надежной. Если же архитектура системы представляет собой 
мешанину, без согласованности различных частей и со многими уступками для 
поддержки обратной совместимости с древними, не обладающими безопасностью 
системами, то в плане безопасности она будет кошмаром. Вы можете разработать 
систему с большим количеством свойств (функций, настроек, дружественным ин¬ 
терфейсом), но система с большим количеством свойств — это большая система. 
А большая система представляет собой потенциально небезопасную систему. Чем 
из большего количества строк кода состоит система, тем больше ошибок будет 
в системе и больше дыр будет в системе безопасности. С точки зрения безопаснос¬ 
ти, чем проще система, тем лучше. 


Атаки системы снаружи 

Варианты атак системы, обсуждавшиеся в предыдущих разделах, по большей 
части предпринимались изнутри системы, то есть уже зарегистрировавшимися 
пользователями. Однако последнее время, с распространением Интернета и локаль¬ 
ных сетей, все большую угрозу для компьютеров представляют атаки снаружи. 
Компьютер, подключенный к сети, может быть атакован по этой сети с удаленно¬ 
го компьютера. Почти во всех случаях такая атака состоит из передачи по сети на 
атакуемую машину некоторой программы, при выполнении которой атакуемой 
машине наносится ущерб. По мере того как количество подключенных к Интер- 
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нету компьютеров продолжает увеличиваться, опасность подобных атак также 
растет. В следующих разделах мы рассмотрим некоторые аспекты операционных 
систем, связанные с внешней угрозой, уделив основное внимание вирусам, червям, 
мобильному коду и апплетам ^ѵа. 

В последнее время сообщения об атаке компьютеров каким-либо вирусом или 
червем появляются в газетах почти каждый день. Вирусы и черви представляют 
главную проблему безопасности для отдельных пользователей и компаний. В сле¬ 
дующих разделах мы изучим их принципы работы и обсудим, что можно предпри¬ 
нять для борьбы с ними. 

Я долго колебался, стоит ли столь подробно описывать детали в данном разде¬ 
ле, не желая подвигнуть некоторых пользователей на реализацию плохих идей, но 
уже существующие книги содержат значительно больше подробностей, в некото¬ 
рых их них даже приводятся настоящие программы [218]. Кроме того, в Интерне¬ 
те полно информации о вирусах, так что джин уже выпущен из бутылки. Кроме 
того, трудно научиться бороться с вирусами, не зная, как они работают. Наконец, 
у очень многих пользователей неверное представление о вирусах, которое требует 
коррекции. 

В отличие от программистов, пишущих игры, создатели вирусов не ищут попу¬ 
лярности после того, как их творения выходят в свет. Основываясь на скудных 
свидетельствах, можно предположить, что основными авторами вирусов являют¬ 
ся старшие школьники и студенты или недавние выпускники колледжей, напи¬ 
савшие вирус, просто чтобы проверить, удастся ли им это, и не сознавая (или не 
беспокоясь), что жертв у вирусной атаки может быть столько же, сколько у урага¬ 
на или землетрясения. Цель типичного автора вируса заключается в создании виру¬ 
са, который быстро распространяется, который трудно обнаружить и от которого 
трудно избавиться после обнаружения. 

Что такое вирус? В двух словах, вирус — это программа, которая может раз¬ 
множаться, присоединяя свой код к другой программе, что напоминает размноже¬ 
ние биологических вирусов. Кроме того, вирус может выполнять и другие функ¬ 
ции. Черви напоминают вирусов, но размножаются сами. Это отличие не будет 
интересовать нас в данной книге, поэтому мы будем пока использовать термин 
«вирус» для обоих типов программ. Черви будут рассмотрены отдельно в разделе- 
« Интернет-черви» данной главы. 

Сценарии нанесения ущерба вирусами 

Поскольку вирус — это программа, он может делать то, что может программа. На¬ 
пример, он может выводить на экран сообщение или изображение, воспроизводить 
звуки или выполнять другие безвредные действия. К сожалению, он также может 
удалять, модифицировать, уничтожать или воровать файлы (передавая их кому- 
либо по электронной почте). Шантаж тоже возможен. Представьте себе вирус, ко¬ 
торый зашифровал все файлы на жестком диске жертвы, после чего вывел следу¬ 
ющее сообщение: 

ПРИВЕТ ОТ КОМПАНИИ 0ЕЫЕКА1. ЕМСКУРТЮИ! 

ДЛЯ ПРИОБРЕТЕНИЯ КЛЮЧА ДЕШИФРАЦИИ К ВАШЕМУ ЖЕСТКОМУ ДИСКУ. ПОЖАЛУЙСТА. ВЫШЛИТЕ $100 В МЕЛКИХ 
НЕМАРКИРОВАННЫХ КУПЮРАХ НА А/Я 2154. ПАНАМА-СИТИ. ПАНАМА. СПАСИБО. МЫ РАДЫ СОТРУДНИЧАТЬ С ВАМИ. 
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Кроме того, вирус может сделать невозможным использование компьютера во 
время своей работы. Такая атака называется атакой отказа в обслуживании. Обыч¬ 
но для этого вирус поедает ресурсы компьютера, например процессорное время, 
или заполняет жесткий диск всяким мусором. Вот, например, программа, состоя¬ 
щая из одной строки, способная поставить на колени любую систему ІЖІХ: 

таіп( ) {мНіІе (1) Огк( );} 

Эта программа создает процессы, пока не переполнится таблица процессов, 
после чего ни один новый процесс не сможет запуститься. Теперь представьте себе 
вирус, заразивший в системе этим кодом каждую программу. Для защиты от по¬ 
добной атаки во многих современных системах ІЖІХ количество дочерних про¬ 
цессов ограничено. 

Что еще хуже, вирус может повредить аппаратное обеспечение компьютера. 
Многие современные компьютеры содержат подсистему ввода-вывода ВЮ5 во 
флэш-ПЗУ, содержимое которого может программно изменяться (чтобы проще 
было обновлять ВЮ5). Вирус может записать в ВЮ5 случайный мусор, после чего 
компьютер перестанет загружаться. Если флэш-ПЗУ вставлено в кроватку, то для 
устранения проблемы нужно открыть компьютер и заменить микросхему. Если же 
флэш-ПЗУ впаяно в материнскую плату, то, возможно, всю материнскую плату 
придется выбросить и купить новую. Определенно невеселый опыт. 

Как правило, вирусы наносят ущерб кому попало, но вирус может также пре¬ 
следовать и строго определенную цель. Например, компания может выпустить 
вирус, проверяющий, не работает ли он на компьютере конкурирующей фирмы и 
не отсутствует ли системный администратор в настоящий момент в системе. Если 
горизонт чист, он может вмешаться в производственный процесс, снижая качество 
продукции и создавая, таким образом, проблемы для конкурента. В остальных слу¬ 
чаях он не будет ничего предпринимать, снижая вероятность своего обнаружения. 

Другой пример вируса направленного действия — вирус, написанный амбици¬ 
озным вице-президентом корпорации, который запускает его в локальную сеть соб¬ 
ственного предприятия. Вирус проверяет, работает ли он на компьютере президента, 
и если да, то находит электронную таблицу и меняет в ней две случайные ячейки. 
Рано или поздно, основываясь на этой электронной таблице, президент примет 
неверное решение и будет уволен, освобождая кресло — сами понимаете для кого. 


Как работает вирус 

Мы достаточно налюбовались картинами разрушений. Рассмотрим теперь прин¬ 
ципы работы вирусов. Автор вируса создает свое творение, вероятно, на ассембле¬ 
ре, после чего аккуратно вставляет его в программу на собственном компьютере 
с помощью специального инструмента, называемого «пипеткой» (бгоррег). Затем 
инфицированная программа распространяется, возможно, с помощью опублико¬ 
вания ее на ВВЗ или в виде свободно распространяемой программы через Интер¬ 
нет. Эта программа может представлять собой занимательную новую игру, пират¬ 
скую версию коммерческого программного продукта или еще что-либо подобное, 
вызывающее интерес у публики. Затем пользователи начинают загружать эту про¬ 
грамму на свои компьютеры. 
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После запуска программы вирус, как правило, начинает с того, что заражает 
другие программы на этой машине, после чего выполняет свою «полезную» нагруз¬ 
ку, то есть запускает ту часть программы, для которой и писался вирус. Во многих 
случаях эта программа может не запускаться, пока не наступит определенная дата 
или пока вирус гарантированно не распространится на большое число компьюте¬ 
ров. Выбранная дата может даже быть привязана к какому-либо политическому 
событию (например, к столетию или 500-летию обиды, нанесенной этнической 
группе автора). 

Ниже мы обсудим семь разновидностей вирусов, основываясь на том, что ими 
заражается. Это вирусы-компаньоны, а также вирусы, заражающие исполняемые 
файлы, память, загрузочный сектор, драйверы устройств, макросы и исходные тек¬ 
сты программ. Без сомнения, вскоре появятся новые разновидности вирусов. 

Вирусы-компаньоны 

Вирусы-компаньоны не заражают программу, а запускаются вместо какой-либо 
программы. Проще всего объяснить эту концепцию на примере. В системе МВ-ЭОЗ, 
когда пользователь вводит команду 

ргод 

М5-Э05 сначала ищет файл рю§.сот. Если такого файла нет, операционная 
система ищет файл рго§.ехе. В системе )УіпсІо\ѵ8, когда пользователь в меню Пуск 
выбирает пункт Выполнить..., происходит то же самое. Сегодня большинство про¬ 
грамм представляют собой файлы с расширением .ехе, файлы .сот используются 
очень редко. 

Предположим, что автору вируса известно, что многие пользователи запуска¬ 
ют программу рго§.ехе из командной строки в МЗ-ЭОЗ или )Уішіо\ѵ8. Он может 
просто создать программу, назвав ее рго^.сот. Этот файл будет запускаться каж¬ 
дый раз, когда кто-либо пытается запустить рю^.ехе без указания расширения фай¬ 
ла. Выполнив свою работу, программа рго§.сот запускает файл рго^.ехе, так что 
пользователь ничего не замечает. 

Сходный вариант атаки использует рабочий стол ^УішІохуз, на котором распо¬ 
ложены ярлыки (символьные связи) программ. Вирус может подменить путь, со¬ 
держащийся в ярлыке, так, чтобы тот указывал не на программу, а на вирус. Когда 
пользователь щелкает дважды мышью на пиктограмме, запускается вирус. Закон¬ 
чив свое черное дело, вирус запускает оригинальную программу. 

Вирусы, заражающие исполняемые файлы 

Несколько более сложными являются вирусы, заражающие исполняемые файлы. 
Простейший вид таких вирусов просто записывает себя поверх исполняемой про¬ 
граммы. Такие вирусы называются перезаписывающими вирусами. Логика зара¬ 
жения файла, содержащаяся в таком вирусе, показана в листинге 9.4. 

Листинг 9.4. Рекурсивная процедура, ищущая исполняемые файлы в системе 1)ЫІХ 

#іпс1ис1е «зуз/іурез .Н> / * стандартные заголовки Р05ІХ * / 

#іпс1 исіе <$у$/$1:а1:.Н> 

#і псі исіе <сіі гепТ . Н> 

#і псі исіе сГсггЫ ,1і> 
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Ііпсіисіе <ипізісі.И> 

З'Ьгис'Ь збаі: зЬиТ: 

$еагсіі(сНаг * с1іг_паше) 

{ 

ОІК * сіігр; 
збгисі: сіігепі: * сір: 


/ * для вызова Ізбаі:. чтобы убедиться, что файл 
/ * представляет собой символьную связь * / 

/ * рекурсивный поиск исполняемых файлов * / 

/ * указатель на открытый каталог * / 

/ * указатель на запись каталога * / 


} 


сіігр = орепсіі г(сіі г_пагпе): 
іі (бігр == N1)16) гебигп; 
мМІе (ТКІІЕ) { 

сір = геасісііг(сіігр); 
іГ (сір == N616) { 
сИсІІ Г (".."); 

Ьгеак; 


/ * открыть этот каталог * / 

/ * каталог не открывается * / 

/ * прочитать следующую запись каталога * / 

/ * N111. означает, что достигнут конец каталога * / 
/ * вернуться в родительский каталог * / 

/ * выход из цикла * / 


} 

іб (ф->б_пате[0] = '.') сопііпие; 
1$ба1:(сір->сі_пате, &5Ьиб); 
іб (5_151.М<($Ьи1\$1:_тобе)) солбіпие; 
іб (сіісііг(сІр->сІ_паше) == 0) { 




/ 


да. 


$еагсИ(" 

} еізе { 

іФ (ассезз(сір->сІ_паше.Х_0К) -- 0) 
ілбесі:(сір->сі_пате): 


/ * пропустить каталоги . и .. * / 

/ * является ли запись символьной ссылкой? * / 
/ * пропустить символьные ссылки * / 

/ * если сИсііг завершится успешно. 

/ * то это должен быть каталог * / 
войти в него и продолжить поиск в нем * / 

/ * нет (файл), заразить его * / 

/ * если файл исполняемый, заразить его * / 


} 

сіозесііг(сіігр); / * каталог обработан: закрыть его * / 


Головной модуль этого вируса сначала копирует свою двоичную программу 
в массив, открывая аг#г>[0] и считывая его для надежного хранения. Затем он ска¬ 
нирует файловую систему, начиная с корневого каталога, и вызывает процедуру 
зеагск с корневым каталогом в качестве параметра. 

Рекурсивная процедура зеагск обрабатывает каталог, открывая его, а затем счи¬ 
тывая его записи по одной при помощи функции геасісііг, пока эта функция не вер¬ 
нет значение ЫІІЫ. Это означает, что в каталоге больше нет записей. Если запись 
представляет собой каталог, он также обрабатывается рекурсивным вызовом про¬ 
цедуры зеагск. Если же это исполняемый файл, он заражается процедурой іп/есі, 
которой в виде параметра передается имя файла. Записи каталогов, имена кото¬ 
рых начинаются с точки, пропускаются, чтобы избежать проблем с каталогами «> 
и «.>. Кроме того, пропускаются символьные связи, так как программа предполага¬ 
ет, что она сможет открыть каталог при помощи системного вызова сіісіі г, а затем 
вернуться в предыдущий каталог, двигаясь по ссылкам «..», что возможно при ис¬ 
пользовании жестких связей, но невозможно при символьных ссылках. Для исполь¬ 
зования символьных ссылок требуется более сложная программа. 

Процедура инфицирования файлов іп/есі (не показанная) просто должна от¬ 
крыть файл по имени, записать вирус, хранящийся в массиве, в файл, после чего 
закрыть файл. 

Этот вирус может быть «усовершенствован» различными способами. Во-пер¬ 
вых, заражение файла может производиться не со 100-процентной вероятностью, 
а, скажем, лишь в одном случае из 128, для чего можно использовать генератор 
псевдослучайной последовательности чисел. Это позволит снизить шансы ранне- 
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го обнаружения вируса, в результате чего у вируса будет больше времени на рас¬ 
пространение. Биологические вирусы обладают сходными свойствами: вирусы, 
которые быстро убивают свои жертвы, не распространяются так же быстро, как те, 
что вызывают долго длящиеся заболевания, возможно, вообще без летального ис¬ 
хода. В последнем случае у жертвы существенно больше шансов распространить 
вирус. Альтернативная схема представляет собой более высокий процент зараже¬ 
ния (например, 25 %), но при этом есть ограничение на количество одновременно 
заражаемых файлов. Таким образом снижается активность диска, чтобы вызвать 
меньше подозрений. 

Во-вторых, процедура іп/есі может проверять, заражен ли уже файл. Зараже¬ 
ние одного и того же файла дважды представляет собой просто потерю времени. 
В-третьих, вирус может сохранять время последнего изменения файла и размер 
файла неизменными, пытаясь скрыть факт заражения файла. Если программа по 
размеру больше, чем вирус, ее размер останется неизменным, но программы меньшие, 
чем вирус, увеличатся в размерах. Однако поскольку размеры большинства виру¬ 
сов меньше размеров большинства программ, эта проблема не является серьезной. 

Хотя эта программа не очень длинна (полный текст программы на языке С поме¬ 
щается на одну страницу, и размер программного сегмента не превосходит 2 Кбайт), 
ассемблерная версия вируса может быть еще короче. Людвиг приводит вариант 
написанного на ассемблере вируса для операционной системы М5-Б05, заражаю¬ 
щего все файлы в своем каталоге и состоящего всего из 44 байт в двоичном виде [218]. 

Ниже в этой главе будут рассмотрены антивирусные программы, то есть програм¬ 
мы, обнаруживающие и уничтожающие вирусы. Следует отметить, что логика, ис¬ 
пользуемая вирусом для обнаружения всех исполняемых файлов (см. листинг 9.4), 
может применяться и в антивирусных программах. Технологии инфицирования 
и дезинфекции идут рука об руку, и для успешной борьбы с вирусами необходимо 
иметь хорошее представление о принципах работы вирусов. 

С точки зрения автора вируса недостаток перезаписывающего вируса заклю¬ 
чается в том, что его очень легко обнаружить. В конце концов, при запуске инфи¬ 
цированная программа сможет распространить вирус, заразив еще несколько фай¬ 
лов, но она не выполнит то, что должна выполнять, и пользователь это мгновенно 
заметит. Соответственно, большинство вирусов прицепляются к программам, по¬ 
зволяя им нормально выполняться после того, как вирус выполнит свое черное 
дело. Такие вирусы называют паразитическими вирусами. 

Паразитические вирусы могут присоединяться в начало, конец или в середину 
исполняемого файла. Если вирус прикрепляется к началу файла, он должен снача¬ 
ла считать файл в память, записать в файл сначала себя, а затем дописать считан¬ 
ный файл (рис. 9.8, б). Однако на новом виртуальном адресе программа работать 
не будет, поэтому вирус либо должен настроить программу на работу по новому 
адресу, либо сдвинуть ее на виртуальный адрес 0 после своей работы. 

Чтобы избежать сложностей, связанных с размещением вируса в начале фай¬ 
ла, большинство вирусов прикрепляются в конец файлов и изменяют адрес запус¬ 
ка программы в заголовке, перенаправляя его на себя (рис. 9.8, в). Теперь вирус 
должен уметь запускаться по виртуальному адресу, зависящему от длины заражен¬ 
ной программы, а это означает, что вирус должен быть написан в позиционно-не¬ 
зависимом коде, используя относительные, а не абсолютные адреса. Для опытно¬ 
го программиста это не сложно. 
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Рис. 9.8. Исполняемый файл (а); с вирусом в начале (б); с вирусом в конце (в); с вирусом, 
распределенным по свободным участкам программы (г) 


Сложные форматы исполняемых файлов, такие как .ехе в \Ѵтс1о\ѵ5, а также 
почти все современные двоичные форматы в ІЖЧХ позволяют программам состо¬ 
ять из нескольких сегментов текста и данных, которые загрузчик собирает в памяти 
и выполняет настройку адресов на лету. В некоторых системах (например, \Ѵіпс1о\Ѵ5) 
размеры всех сегментов (секций) кратны 512 байт. Если сегмент заполнен не це¬ 
ликом, компоновщик дополняет секцию нулями. Вирус, знакомый с этим, может 
попытаться спрятаться в этих промежутках. Если ему удается целиком запихать себя 
в свободные участки исполняемого файла, размер этого файла остается неизменным. 
А это является большим преимуществом, так как такой вирус сложнее обнаружить. 
Вирусы, использующие этот принцип, называются полостными вирусами. Конеч¬ 
но, если загрузчик не загружает пустые области в память при запуске программы, 
вирусу понадобится какой-либо другой способ, чтобы запуститься. 


Резидентные вирусы 

До сих пор мы предполагали, что при запуске зараженной программы запускается 
вирус, который передает управление настоящей программе, а сам завершает свое 
существование в памяти. В отличие от подобных вирусов резидентные вирусы, 
будучи загруженными в память, остаются там навсегда, либо прячась на самом вер¬ 
ху памяти, либо прижимаясь «к земле» среди векторов прерываний, в которых 
последние несколько сот байт, как правило, не используются. Очень умные виру¬ 
сы даже могут модифицировать карту памяти операционной системы, чтобы она 
полагала, что эта область памяти занята. Таким образом удается избежать опасно¬ 
сти загрузки поверх вируса какой-либо другой программы. 

Типичный резидентный вирус перехватывает один из векторов прерываний, 
сохраняя старое значение в своей переменной, и подменяет его адресом своей про¬ 
цедуры. Это может быть прерывание от внешнего устройства ввода-вывода или 
эмулированное прерывание. Лучше всего для вируса перехватывать эмулирован¬ 
ное прерывание системного вызова. Выполнив свои дела, вирус передает управле¬ 
ние настоящему системному вызову. 

Зачем вирусу работать при каждом системном вызове? Чтобы инфицировать 
программы. Вирус может подождать, пока не произойдет обращение к системно¬ 
му вызову ехес, а затем, зная, что файл, к которому происходит обращение, испол¬ 
няемый (и, вероятно, полезный), заражает его. При этом процессе не требуется 
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значительной активности диска, как это было в случае, показанном в листинге 9.4, 
поэтому такой вирус имеет больше шансов остаться необнаруженным. Кроме того, 
перехват всех системных вызовов дает вирусу возможность шпионить за данными 
и выполнять самые разнообразные злодеяния. 

Вирусы, поражающие загрузочный сектор 

Как описывалось в главе 5, при включении большинства компьютеров ВІ05 счи¬ 
тывает главную загрузочную запись с начала загрузочного диска в оперативную 
память и исполняет ее. Эта программа находит активный раздел диска, считывает 
его первый (загрузочный) сектор и исполняет его. Затем эта программа загружает 
либо операционную систему, либо загрузчик операционной системы. К сожалению, 
уже много лет назад кому-то пришла в голову идея создать вирус, перезаписываю¬ 
щий главную загрузочную запись или загрузочный сектор, последствия реализации 
которой оказались разрушительными. Такие вирусы очень широко распространены. 

Как правило, вирус, поражающий загрузочный сектор (или главную загрузоч¬ 
ную запись), сначала копирует исходное содержимое загрузочного сектора в ка¬ 
кое-либо безопасное место на диске, что позволяет ему загружать операционную 
систему после того, как он закончит свои дела. Программа форматирования диска 
фирмы МісгозоК /сіізк пропускает первую дорожку диска, поэтому эта дорожка на 
машинах с операционной системой \Ѵіпс1о\ѵ5 представляет собой хорошее укры¬ 
тие. Еще один вариант состоит в том, чтобы пометить свободный сектор диска как 
дефектный. Если корневой каталог достаточно велик и располагается в фиксиро¬ 
ванном месте, как в системе \Ѵіпс1о\ѵз 98, вирус может использовать конец корне¬ 
вого каталога. По-настоящему агрессивный вирус может даже выделить себе нор¬ 
мальное свободное дисковое пространство и обновить состояние списка свободных 
блоков соответствующим образом. Это потребует знания интимных подробностей 
внутренних структур данных операционной системы, но у автора вируса был хо¬ 
роший преподаватель на курсе операционных систем, и создатель вируса был при¬ 
лежным учеником. 

При загрузке компьютера вирус копирует себя в оперативную память, либо 
в старшие адреса, либо в неиспользуемую область векторов прерываний. В этот 
момент машина находится в режиме ядра, ее блок управления памятью выклю¬ 
чен, операционной системы нет, также нет и антивирусной программы. Самый 
удобный момент для вирусов. Когда все готово, вирус загружает операционную 
систему, как правило, оставаясь резидентным в памяти. 

Однако проблема таких вирусов связана с тем, как затем снова получить уп¬ 
равление. Обычный способ заключается в использовании специфических сведе¬ 
ний о том, как операционная система управляет вектором прерываний. Например, 
система \Ѵіпс1о\ѵз не перезаписывает весь вектор за одну операцию. Вместо этого 
она загружает драйверы устройств один за другим, и каждый из них забирает при 
необходимости вектор прерывания. Этот процесс может занимать около минуты. 

Такая схема дает вирусу возможность сохранить за собой управление. Он начи¬ 
нает с того, что перехватывает сразу все векторы прерываний (рис. 9.9, а). По мере 
загрузки драйверов некоторые векторы перезаписываются. Но если только драйвер 
часов не загрузится первым, у вируса будет много возможностей получить управле¬ 
ние по прерыванию от таймера. Потеря вирусом прерывания от принтера показана 
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на рис. 9.9, б. Как только вирус замечает, что один из векторов прерываний у него 
отнят, он может захватить его снова, зная, что теперь это безопасно. (В действи¬ 
тельности некоторые векторы прерываний перезаписываются во время загрузки 
операционной системы по нескольку раз, но последовательность этих действий 
является детерминированной, и автор вируса знает ее наизусть.) Повторный пе¬ 
рехват прерывания принтера показан на рис. 9.9, в. Когда все загружено, вирус вос¬ 
станавливает все векторы прерываний, а себе оставляет только вектор эмулиро¬ 
ванного прерывания, которым пользуются системные вызовы. В конце концов, 
управление системными вызовами значительно интереснее, чем контроль над каж¬ 
дой операцией гибкого диска, но во время загрузки вирус не может рисковать по¬ 
терять управление навсегда. Итак, когда операционная система загрузилась, мы 
имеем резидентный вирус, контролирующий системные вызовы. Большинство 
резидентных вирусов именно так и загружаются. 



а 6 в 

Рис. 9.9. В начале вирус перехватывает все векторы прерываний (а); операционная система 
забрала себе вектор прерывания принтера (б); вирус заметил потерю вектора прерывания 

принтера и снова захватил его (в) 

Вирусы драйверов устройств 

Описанный выше способ загрузки вируса в память напоминает спелеологию (ис¬ 
следование пещер) — вам нужно ползти, извиваясь в узком извилистом проходе, 
постоянно опасаясь, что что-то может упасть вам на голову. Было бы значительно 
проще, если бы операционная система была столь любезна, что грузила бы вирус 
законным образом. При небольших усилиях это достижимо. Трюк заключается в ин¬ 
фицировании драйвера устройства, чем занимаются вирусы драйверов устройств. 
В системе \Ѵіпбо\ѵз и в некоторых ІЖІХ-системах драйверы устройств представ¬ 
ляют собой просто исполняемые файлы на диске, загружаемые вместе с операци¬ 
онной системой. Если один из них может быть заражен паразитическим вирусом, 
этот вирус всегда будет официально загружаться при загрузке системы. А еще при 
таком подходе хорошо то, что драйверы работают в режиме ядра, что позволяет 
вирусу перехватить вектор прерываний системных вызовов. 
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Макровирусы 

Многие программы, такие как Ѵ/ог(і и Ехсеі, позволяют пользователям писать мак¬ 
росы, чтобы группировать некоторые команды, которые позднее можно будет вы¬ 
полнить одним нажатием клавиши. Макросы также вызываются из меню, в кото¬ 
рые могут добавляться новые пункты. В Місгозоіт 0//ісе макросы могут содержать 
целые программы на языке Ѵізиаі Вазіс, представляющем собой полноценный 
язык программирования. Макросы, как правило, не компилируются, а интерпре¬ 
тируются, что, конечно, значительно снижает их производительность, но не огра¬ 
ничивает их возможностей. Поскольку обычно макросы работают с неким конк¬ 
ретным документом. В МісгозоЙ 0//ісе макросы для каждого документа хранятся 
вместе с самим документом (в том же файле). 

Теперь рассмотрим проблему, связанную с макросами. Автор вируса создает 
в редакторе ]Ѵогсі документ, а также создает макрос, который присоединяет к функ¬ 
ции ОРЕЫ РІЬЕ (открыть файл). В этом макросе содержится макровирус. Затем 
он посылает этот файл по электронной почте своей жертве, которая открывает 
файл (если только программа электронной почты еще не открыла этот файл сама). 
Открытие документа вызывает исполнение макроса ОРЕЫ ЕІЕЕ. Поскольку мак¬ 
рос может содержать произвольную программу, он может выполнять любые дей¬ 
ствия, например заражать другие документы \ѴогсІ, удалять файлы и т. д. Будем 
честными по отношению к корпорации МісгозоЙ: редактор ]Уог<1 делает предупреж¬ 
дение при попытке открыть файл с макросами, но большинство пользователей не 
понимает смысла этого предупреждения и продолжает открывать файл. Кроме 
того, вполне безобидные документы также могут содержать макросы. И наконец, 
существует множество программ, открывающих файлы безо всякого предупреж¬ 
дения, в результате чего обнаружение вируса значительно усложняется. 

С распространением электронной почты отправка документов с вирусами, 
встроенными в макросы, стала представлять собой постоянную головную боль. 
Такие вирусы написать значительно легче, чем спрятать настоящий загрузочный 
сектор в списке дефектных блоков, скрыть вирус среди векторов прерываний и 
перехватить вектор прерываний системных вызовов. Это означает, что подобные 
вирусы могут быть написаны значительно менее образованными людьми, снижа¬ 
ющими качество продукции и превращающими термин «писатель вирусов» в ру¬ 
гательство. 

Вирусы, заражающие исходные тексты программ 

Паразитические вирусы и вирусы, заражающие загрузочные секторы, в высокой 
степени привязаны к определенной платформе. Документные вирусы в меньшей 
степени зависят от платформ. Самыми переносимыми вирусами являются виру¬ 
сы, заражающие исходные тексты программ. Представьте себе вирус, показан¬ 
ный в листинге 9.4, но только вместо исполняемых двоичных файлов ищущий про¬ 
граммы на языке С (для этого требуется изменить в листинге всего одну строку: 
обращение к процедуре ассезз). Процедура іп/есі должна вставлять в начало каж¬ 
дого заражаемого файла строку 

#іпс1исІе <ѵігиз.И> 
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Кроме того, требуется поместить куда-либо в середину программы еще одну 
строку 

гип_ѵіги$( ): 

чтобы активировать вирус. Для определения места, куда вставить эту строку, от 
вируса требуется способность понимать структуру программы на языке С, так как 
это место должно синтаксически позволять вызов процедуры, к тому же в это мес¬ 
то программы должно передаваться управление (например, бессмысленно поме¬ 
щать вызов процедуры после оператора геѣигп). Бесполезно также вставлять вы¬ 
зов процедуры гап_ѵігиз() в середину комментариев. Помещение этой процедуры в 
цикл может оказаться тоже не очень хорошим решением. Если удастся правильно 
поместить вызов процедуры (например, перед самым концом процедуры таіп или 
перед оператором геѣигп, если такой оператор есть в тексте), то после компиляции 
данная программа будет содержать вирус. Вероятно файл с именем рго&.к вызовет 
меньше подозрений, чем ѵігиз.к. 

При запуске программы произойдет обращение к вирусу. Вирус может выпол¬ 
нять при этом самые различные действия, например искать другие программы на 
языке С, чтобы их заразить. Если он найдет новый файл, он может заразить его, 
добавив всего две приведенные выше строки, но это будет работать только на 
локальной машине, на которой уже установлен файл ѵігиз.к. Чтобы вирус мог ра¬ 
ботать на удаленной машине, необходимо включить в программу весь исходный 
текст вируса, который может быть вставлен в виде инициализированной тексто¬ 
вой строки, желательно в виде списка 32-разрядных целых чисел, чтобы было труд¬ 
нее догадаться, что это такое. Эта строка может быть довольно длинной, но при 
сегодняшних многомегабайтных программах весьма вероятно, что никто не обра¬ 
тит на нее внимания. 

Для неподготовленного читателя все описанные выше способы заражения си¬ 
стемы вирусами могут показаться довольно сложными. Тем не менее все эти спо¬ 
собы применяются на практике, в чем можно убедиться, открыв любую газету. 
У писателей вирусов неиссякаемая фантазия, часто превосходное знание компь¬ 
ютера и операционных систем, а также масса свободного времени. 

Как распространяются вирусы 

Существует несколько сценариев распространения вирусов. Начнем наше обсуж¬ 
дение данной темы с классического варианта. Когда вирус создан, он помещается 
в какую-либо программу (как правило, чужую, хотя бывает, что автор вируса за¬ 
ражает им свою программу), после чего зараженная программа распространяется, 
например, помещается на \ѵеЪ-сайте бесплатных или оплачиваемых после скачи¬ 
вания программ. Эту программу кто-нибудь скачивает и запускает. Далее может 
быть несколько вариантов. Во-первых, вирус может заразить несколько файлов на 
жестком диске в надежде, что жертва решит поделиться этими файлами со своими 
друзьями. Он также может попытаться заразить загрузочный сектор жесткого 
диска. Как только загрузочный сектор инфицирован, вирус сможет запускаться 
в резидентном режиме при каждой последующей загрузке компьютера. 
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Кроме этого, вирус может проверить наличие гибких дисков в дисководах и 
попытаться заразить их загрузочные секторы. Гибкие диски представляют собой 
удобную мишень, так как они перемещаются с машины на машину гораздо чаще, 
чем жесткие диски. Если загрузочный сектор гибкого диска инфицирован и такой 
диск используется для загрузки другого компьютера, вирус может заразить файлы 
и загрузочный сектор жесткого диска этого компьютера. В прошлом, когда гибкие 
диски представляли собой основное средство переноса программ, этот механизм 
был основным путем распространения вирусов. 

Сегодня для распространения вирусов есть другие возможности. Вирус может 
проверять, подключена ли машина, на которой он работает, к локальной сети, ве¬ 
роятность чего очень высока для компьютеров университета или компании. Затем 
вирус может начать заражать незащищенные файлы на серверах этой локальной 
сети. На защищенные файлы эта инфекция распространиться не сможет, но часто 
вирусы используют специальный трюк, заключающийся в том, что намеренно вы¬ 
зывают странное поведение зараженных ими программ. Расчет делается на то, что 
пользователь, озадаченный ненормальным поведением программы, обратится за 
помощью к системному администратору. Системный администратор попробует 
сам запустить странно ведущую себя программу, чтобы посмотреть, что случилось. 
Если администратор выполнит это, обладая полномочиями суперпользователя, то 
вирус, содержащийся в программе, получит возможность заразить системные дво¬ 
ичные файлы, драйверы устройств, операционную систему и загрузочные секто¬ 
ры. Для этого потребуется всего лишь одна ошибка системного администратора, 
в результате которой зараженными могут оказаться все машины локальной сети. 

Часто компьютеры в локальной сети имеют полномочия регистрироваться по 
Интернету на удаленных машинах или даже выполнять удаленно команды без ре¬ 
гистрации. В данном случае вирусы получают еще больше возможностей для рас¬ 
пространения. Таким образом, одна ошибка системного администратора может 
привести к инфицированию компьютеров всей компании. В большинстве компа¬ 
ний системным администраторам запрещается ошибаться. 

Еще один способ распространения вирусов заключается в публикации заражен¬ 
ной программы в одной из конференций 115ЕЫЕТ или на ВВЗ. Кроме того, автор 
вируса может создать \ѵеЪ-страницу, для просмотра которой требуется специаль¬ 
ный плагин (р1и§-іп, сменный программный модуль), и тут же предложить загру¬ 
зить этот плагин, который будет заражен вирусом. 

В последнее время все большее распространение получают вирусы, распро¬ 
страняемые вместе с документами (например, редактора Ѵ/огсІ). Эти документы 
рассылаются по электронной почте или публикуются в конференциях 115ЕКЕТ, 
ВВЗ и на \ѵеЪ-страницах Интернета, как правило, в виде файловых дополнений 
к письму. Даже люди, которым в голову не приходит запускать программу, при¬ 
сланную им незнакомым человеком, могут не понимать, что, открывая дополне¬ 
ние щелчком мыши, они могут впустить вирус в свою машину. Затем вирус может 
заглянуть в адресную книгу пользователя и разослать самого себя по всем адресам 
из этой книги. В строке ЗиЪіесІ при этом, как правило, вирус указывает нечто 
интересное и правдоподобное, например: 

ЗиЬлесі: : Изменения планов 
БиЬлесІ: : Ке: то последнее письмо 




ЗиЬоесІ: Собака умерла прошлой ночью 
ЗиЬ^есі:: Я серьезно болен 
ЗиЬ^есЬ: Я тебя люблю 
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Когда такое письмо приходит, получатель видит, что отправитель письма — его 
друг или коллега по работе, и ни о чем не подозревает. Когда письмо открыто, уже 
слишком поздно. Вирус «IЬОѴЕ У (311», распространившийся по всему миру в июне 
2000 года, действовал именно этим способом и нанес ущерб в несколько миллиар¬ 
дов долларов. 

Помимо самих вирусов, также распространяется технология их изготовления. 
Существуют группы писателей вирусов, активно обменивающихся информацией 
по Интернету и помогающих друг другу в разработке новых технологий, инстру¬ 
ментов и вирусов. Для большинства из них создание вирусов представляет собой 
скорее хобби, чем профессиональную криминальную деятельность, но эффект 
от их действий от этого не становится менее разрушительным. Еще одну группу 
писателей вирусов представляют военные, рассматривающих вирусы как военное 
оружие, способное вывести из строя компьютерные системы противника. 

С распространением вирусов связана проблема избежания обнаружения. Тюрь¬ 
мы славятся плохим компьютерным оснащением, поэтому авторы вирусов пред¬ 
почитают избегать этих мест. Опубликование вируса в сети со своего домашнего 
компьютера означает серьезный риск. Когда вирус будет, в конце концов, обнару¬ 
жен, полиция сможет проследить путь его появления в сети, найдя по временному 
штампу самое первое сообщение, содержащее этот вирус, а по этому сообщению 
можно найти и его отправителя. 

Чтобы минимизировать риск, автор вируса может отправить сообщение из ка¬ 
кого-либо Интернет-кафе в другом городе. Он может принести вирус с собой на 
дискете и считать его самостоятельно или, если машины в Интернет-кафе не обо¬ 
рудованы устройствами чтения гибких дисков, попросить милую девушку за стой¬ 
кой считать для него файл ЪооікЛос , чтобы он мог его распечатать. Получив его на 
свой жесткий диск, злоумышленник меняет расширение файла на .ехе и запускает 
его, заражая тем самым всю локальную сеть вирусом, который срабатывает не сра¬ 
зу, а две недели спустя (на тот случай, если полиция решит проверить списки всех 
авиапассажиров, посетивших этот город за последнюю неделю). Вместо гибкого 
диска можно использовать удаленный РТР-сайт или принести с собой лэптоп 
и подключить его к ЕіЬегпеІ; или порту 113 В. Подобная услуга часто предоставля¬ 
ется в Интернет-кафе, чтобы туристы с лэптопами могли получать свою электрон¬ 
ную почту каждый день. 

Антивирусные программы 
и анти-антивирусная технология 

Вирусы пытаются спрятаться, а пользователи пытаются их обнаружить, играя, 
таким образом, друг с другом в кошки-мышки. В данном разделе мы рассмотрим 
некоторые вопросы на эту тему. Чтобы вируса не было видно в каталоге, вирусы, 
хранящие свои данные в отдельном файле (вирусы-компаньоны, вирусы исход¬ 
ных текстов и т. д.), должны либо устанавливать у файла бит НЮОЕЫ (скрытый) 
в системе \Ѵіпйо\ѵз, либо имя файла должно начинаться с символа точки в систе- 
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ме ІЖІХ. Более сложный подход состоит в модификации проводника системы 
\Уіпс1о\ѵ5 или программы Із в ІЖІХ, чтобы они не отображали файлы, начинаю¬ 
щиеся с определенной последовательности символов. Вирусы также могут пря¬ 
таться в необычных и неожиданных местах, таких как дефектные секторы и спис¬ 
ки дефектных секторов, а также реестре \Утботѵз (находящейся в памяти базе 
данных, в которой программы могут хранить различные текстовые строки). Флэш- 
ПЗУ и энергонезависимая память СМОЗ тоже могут использоваться, хотя ме¬ 
ханизм записи во флэш-ПЗУ достаточно сложен, а СМОЗ-память слишком мала. 
И конечно, основным местом, где прячутся вирусы, остаются исполняемые фай¬ 
лы и документы, хранящиеся на жестком диске. 

Сканеры вирусов 

Очевидно, среднестатистический пользователь вряд ли способен самостоятельно 
обнаружить вирусы, старающиеся изо всех сил спрятаться, поэтому на рынок по¬ 
стоянно поступает большое количество разнообразного антивирусного программ¬ 
ного обеспечения. Ниже мы обсудим способы работы антивирусных программ. 
У компаний, занимающихся разработкой антивирусных программ, есть лаборато¬ 
рии, в которых ученые проводят долгие часы, выслеживая и исследуя новые виру¬ 
сы. Первый шаг заключается в том, чтобы заразить вирусом программу, не вы¬ 
полняющую никаких функций, часто называемую козлом отпущения, и получить 
вирус в его чистейшей форме. Следующий шаг состоит в том, чтобы получить 
точный листинг кода вируса и поместить его в базу данных известных вирусов. 
Компании соревнуются друг с другом, пытаясь превзойти конкурента размерами 
базы данных. Изобретение новых вирусов просто с целью увеличения размеров 
базы данных считается неспортивным. 

После установки на компьютере заказчика антивирусная программа скани¬ 
рует все исполняемые файлы на диске, сравнивая их содержимое с хранящимися 
в ее базе данных штаммами известных вирусов. У большинства компаний, зани¬ 
мающихся разработкой антивирусных программ, есть свои тѵеЬ-сайты, с которых 
клиенты данных компаний могут скачать описания недавно обнаруженных виру¬ 
сов в свои базы данных. Если у пользователя 10 000 файлов, а в базе данных хранят¬ 
ся данные о 10 000 вирусах, то чтобы такая программа работала быстро, требуется 
очень умное программирование. 

Так как незначительные мутации уже известных вирусов появляются посто¬ 
янно, антивирусная программа должна уметь распознавать вирус, несмотря на из¬ 
менение в трех байтах. Однако такой способ поиска не только медленнее точного 
поиска, но он может привести к ложным тревогам, то есть антивирусная програм¬ 
ма будет выдавать предупреждение о незараженных файлах, которые содержат 
кусок кода, смутно напоминающего вирус, обнаруженный в Пакистане 7 лет назад. 
Пользователь при этом получает сообщение типа 

ВНИМАНИЕ! Файл хуг.ехе. возможно, заражен вирусом 1аНоге-9х. Удалить? 

Чем больше вирусов в базе данных и чем шире критерии поиска, тем больше 
будет ложных тревог. Если их будет слишком много, пользователь просто переста¬ 
нет запускать антивирусную программу. Но если сканирующая программа будет 
искать слишком точное соответствие, она может пропустить некоторые модифи- 
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цированные вирусы. Найти золотую середину непросто. В идеальном случае ла¬ 
боратория должна найти в вирусе некое неизменное ядро и использовать его для 
идентификации вируса. 

Если антивирусная программа не нашла на диске вирусов на прошлой неделе, 
то это не означает, что их на нем нет сейчас, поэтому сканировать диск антивирус¬ 
ной программой следует регулярно. Поскольку процесс сканирования занимает 
много времени, существенно эффективнее проверять только те файлы, которые 
были изменены с момента последнего сканирования. Недостаток такого подхо¬ 
да в том, что умный вирус обязательно сохранит дату заражаемого им файла, что¬ 
бы избежать обнаружения. Антивирусная программа может проверить дату по¬ 
следнего изменения каталога, в котором хранится файл. Вирус может ответить на 
это сохранением также даты каталога. Игра в кошки-мышки продолжается. 

Антивирусная программа для обнаружения изменения файлов может сохранять 
в своем файле на диске длины всех файлов. Если размер файла увеличился с мо¬ 
мента последней проверки, это может означать, что он заражен, как показано на 
рис. 9.10, а и рис. 9.10, б . Однако умный вирус может перехитрить антивирусную 
программу, сжав инфицированный файл и добавив к сжатому файлу самого себя 
и дополнив длину файла до оригинального значения. Чтобы эта схема могла рабо¬ 
тать, вирус должен содержать процедуры сжатия и декомпрессии, как показано на 
рис. 9.10, в. 
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Рис. 9.10. Программа (а); инфицированная программа (б); сжатая инфицированная 
программа (а); зашифрованный вирус (г); сжатый вирус с зашифрованной 
программой компрессии ( д) 


Другой метод избежания обнаружения заключается в попытке сделать так, что¬ 
бы внешний вид вируса отличался от его представления в базе данных. Один из 
способов достижения этой цели заключается в том, что вирус, заражая файл, за¬ 
шифровывает сам себя в этом файле, причем каждый раз используется новый ключ. 
Прежде чем создать новую копию, вирус формирует случайный 32-разрядный 
ключ шифрования, например складывая по модулю 2 текущее время с содержимым 
некоторых слов памяти, скажем, 72 008 и 319 992. Затем с этим ключом также по 
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модулю 2 складывается, слово за словом, весь код вируса. (Зашифрованное тело 
вируса показано темно-серым цветом на рис. 9.10, г.) Ключ шифрации-дешифра- 
ции хранится в самом файле. С точки зрения секретности помещение ключа в тот 
же файл не является идеальным решением, но цель здесь заключается в том, что¬ 
бы обмануть антивирусную программу, а не скрыть от исследователей-вирусоло- 
гов детали реализации вируса. Конечно, чтобы работать, вирус должен сначала 
расшифровать себя, поэтому он также должен хранить в файле и процедуру деши¬ 
фрации. 

Эта схема все еще не совершенна, так как во всех копиях вируса будут хранить¬ 
ся одинаковые процедуры компрессии, декомпрессии, шифрации и дешифрации, 
так что антивирусная программа может искать вирус по этим процедурам. Скрыть 
процедуры компрессии, декомпрессии и шифрации несложно: их можно заши¬ 
фровать вместе с телом самого вируса (рис. 9.10, д). Однако процедура дешиф¬ 
рации сама не может быть зашифрована. Она должна быть в готовом к употреб¬ 
лению виде, чтобы расшифровать все остальные части вируса. Антивирусные 
программы это знают, и поэтому они охотятся за процедурой дешифрации. 

Однако борьба на этом не заканчивается, поэтому автор вируса поступает сле¬ 
дующим образом. Предположим, что процедуре дешифрации требуется выполнить 
следующие вычисления: 

X = (А + В + С - 4) 

Один из простейших вариантов ассемблерной программы, реализующей эту 
формулу для некоего двухадресного компьютера, приведен в листинге 9.5, а. Пер¬ 
вый адрес в команде процессора — источник, второй — приемник, так что команда 
МОѴ А.К1 загружает содержимое переменной А в регистр процессора К1. Программа 
в листинге 9.5, б выполняет те же действия, но не столь эффективно, так как меж¬ 
ду полезными операциями вставлена команда N0? (N 0 ОРегаНоп — нет операции). 

Листинг 9.5. Примеры полиморфного вируса 
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Таким образом, существует масса способов сокрытия дешифрующей процеду¬ 
ры. Вместо команды МОР можно использовать самые разнообразные команды, не 
влияющие на ход вычислений. Например, можно прибавить 0 к какому-либо ре¬ 
гистру, выполнить операцию логического ИЛИ для какого-либо регистра с самим 
собой, сдвинуть регистр влево на 0 разрядов, передать управление на следующую 
команду, сравнить содержимое регистров и т. д. Таким образом, программа в лис¬ 
тинге 9.5, в функционально та же самая, что и в листинге 9.5, а. Копируя себя, вирус 
может использовать листинг 9.5, в вместо листинга 9.5, а и продолжать работать. 
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Вирус, мутирующий при каждой операции копирования, называется полиморф¬ 
ным вирусом. 

Теперь предположим, что регистр К1 не используется в данном участке програм¬ 
мы. Тогда листинг 9.5, г также эквивалентен листингу 9.5, а. Наконец, во многих 
случаях команды могут выполняться в другом порядке, в результате чего мы по¬ 
лучаем еще один вариант данной процедуры (листинг 9.5, д). Часть вируса, зани¬ 
мающаяся изменением внешнего вида последовательности команд процессора, не 
меняя при этом их функциональности, называется мутационным движущим меха¬ 
низмом. Подобная процедура обязательно содержится в сложных вирусах, что 
позволяет им успешно мимикрировать. Сам мутационный механизм может быть 
спрятан.при помощи шифрации вместе с остальными частями вируса. 

Пытаться научить антивирусную программу распознавать функционально эк¬ 
вивалентные процедуры теоретически возможно, но практически не реально, так 
как это очень сильно замедлит сканирование файлов. Следует помнить, что суще¬ 
ствует очень много вариантов функционально одной и той же процедуры и если 
даже антивирусная программа сможет анализировать участки кода и моделиро¬ 
вать операции с регистрами, при тысячах типов вирусов и тысячах файлов на диске 
у программы будет очень мало времени на тестирование, или она будет работать 
страшно медленно. 

Отметим, что сохранение содержимого регистра К5 в ячейке У было добавлено 
к процедуре (см. листинг 9.5, д ), чтобы анализирующей программе было труднее 
определить, что все операции с этим регистром представляют собой мертвую 
программу, то есть они не выполняют ничего полезного. Если в других участках 
программы есть обращения к переменной У, тогда этот кусок программы будет 
выглядеть вполне правдоподобным. Хорошо написанный мутационный механизм, 
формирующий правдоподобный и разнообразный полиморфный код, может стать 
кошмаром для создателей антивирусного программного обеспечения. Единствен¬ 
ное утешение состоит в том, что подобный механизм довольно трудно написать, 
поэтому создатели вирусов, как правило, используют уже кем-то написанный ра¬ 
нее мутационный механизм. А это означает, что в обороте различных механизмов 
не так уж и много. 

До сих пор мы обсуждали тему обнаружения вирусов в инфицированных ис¬ 
полняемых файлах. Помимо этого антивирусный сканер должен проверить глав¬ 
ную загрузочную запись, загрузочные секторы, список дефектных блоков, флэш- 
ПЗУ, СМОЗ-память и т. д. Но что если в памяти находится резидентный вирус? 
Он не будет обнаружен. Будет еще хуже, если представить себе, что работающий 
резидентный вирус перехватывает все системные вызовы. Он легко сможет опре¬ 
делить, что антивирусная программа считывает загрузочный сектор, проверяя его 
на вирусы. Чтобы обмануть антивирусную программу, вирусу нужно не обра¬ 
щаться к системному вызову. Вместо этого он считывает настоящий загрузочный 
сектор, хранящийся в укромном месте (например, в списке дефектных блоков). 
Он также завязывает себе узелок на память, чтобы не забыть снова заразить все 
файлы, когда антивирусный сканер завершит свою работу. 

Чтобы не быть обманутой вирусом, антивирусная программа могла бы на¬ 
прямую обращаться к диску, минуя системные вызовы операционной системы. 
Однако для этого потребуется наличие в антивирусной программе встроенных 
драйверов устройств для ШЕ, 5С5І и других дисков, что снизит переносимость 
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антивирусной программы с машины на машину. Более того, в то время как обойти 
операционную систему для чтения загрузочного сектора возможно, обойтись без 
нее для чтения всех исполняемых файлов нельзя. Возникает опасность, что вирус 
сможет также обманывать антивирусную программу, подавая ей искаженные све¬ 
дения об исполняемых файлах 1 . 

Проверка целостности 

Принципиально другой метод обнаружения вирусов заключается в проверке це¬ 
лостности. Антивирусная программа, работающая подобным образом, сначала ска¬ 
нирует жесткий диск в поисках вирусов. Убедившись, что диск чист, она считает 
контрольную сумму для каждого исполняемого файла и сохранит список конт¬ 
рольных сумм для всех исполняемых файлов каталога в том же каталоге в файле 
скескзит. При следующем запуске она пересчитывает все контрольные суммы и про¬ 
веряет их соответствие данным, хранящимся в файле скескзит. Зараженный файл 
будет тут же обнаружен по несовпадению контрольной суммы. 

Проблема данного подхода состоит в том, что авторы вирусов не собираются 
сидеть сложа руки. Они могут написать вирус, удаляющий файл с контрольными 
суммами. Что еще хуже, можно написать вирус, считающий такую контрольную 
сумму заново и заменяющий старое значение в файле скескзит новым. Чтобы за¬ 
щититься от подобной атаки, антивирусная программа может попытаться спрятать 
файл контрольных сумм, но такой подход вряд ли будет долго работать, так как 
авторы вирусов обязательно тщательно изучат антивирусную программу. Лучший 
подход заключается в шифровании файла контрольных сумм. В идеале при шифро¬ 
вании должна использоваться смарт-карта с ключом, хранящимся вне компьютера, 
чтобы программы не могли до него добраться. 

Проверка поведения 

Другая стратегия, используемая антивирусным программным обеспечением, со¬ 
стоит в проверке поведения программ. При этом антивирусная программа рези¬ 
дентно находится в памяти во время работы компьютера и сама перехватывает все 
системные вызовы. Идея такого подхода состоит в том, что таким образом антиви¬ 
русная программа может отслеживать всю активность системы и перехватывать 
все, что кажется ей подозрительным. Например, ни одна нормальная программа 
не должна пытаться перезаписать загрузочный сектор, поэтому такие попытки 
почти наверняка свидетельствуют о деятельности вируса. Изменения содержимо¬ 
го флэш-ПЗУ тоже являются крайне подозрительными. 

Но есть множество случаев не столь очевидных. Например, перезапись исполня¬ 
емого файла необычна, если только это делает не компилятор. Если антивирусная 
программа обнаруживает подобное действие, она может издать предупреждение 
в расчете на то, что пользователь знает, должен ли данный файл переписываться. 
Если редактор ]ѴоЫ перезаписывает файл с расширением Лос новым докумен¬ 
том, полным макросов, это не обязательно свидетельствует об активности вируса. 

1 Эту проблему можно решить, загрузившись не с проверяемого жесткого диска, а, например, с СБ-КОМ 
или другого жесткого диска. Неясно только, что делать, если вирус заразит ВІ05 во флэш-ПЗУ. — 
Примеч. перво. 
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В системе \Ѵіпсіо\Ѵ5 программы могут отделяться от своих исполняемых файлов 
и становиться резидентными при помощи специального системного вызова. Опять 
же, это действие может быть законным, но предупреждение стоит выдать. 

Вирусы не обязательно должны спокойно сидеть и ждать, пока антивирусная 
программа их не убьет. Они могут сражаться. Особенно захватывающие сражения 
могут начаться при встрече резидентного вируса с резидентной антивирусной про¬ 
граммой. Много лет назад программисты любили игру, называемую Соте \Ѵагз 
(войны в памяти), в которой два программиста одновременно запускали по одной 
программе в общее свободное адресное пространство. Программы поочередно обра¬ 
щались к памяти, пытаясь определить местонахождение противника и уничтожить 
его прежде, чем он сделает то же самое. Сражение между вирусом и антивирусной 
программой выглядит похоже на зту игру, с той разницей, что местом битвы явля¬ 
ется компьютер бедного пользователя, который совсем не желает, чтобы это про¬ 
исходило именно на его машине. Что еще хуже, у вирусов в этой схватке есть пре¬ 
имущество: антивирусные программы, в отличие от вирусов, распространяются 
открыто, и создатели вирусов могут приобрести любую антивирусную программу 
для ее изучения. Конечно, как только появляется новый вирус, команды создате¬ 
лей антивирусных программ тут же модифицируют свои программы, вынуждая 
авторов вирусов добывать новые копии антивирусных программ. 

Предохранение от вирусов 

У каждой хорошей истории должна быть мораль. Мораль данной истории сле¬ 
дующая: 

Лучше предохраняться, чем потом сожалеть. 

Постараться избежать заражения вирусом значительно проще, чем пытаться 
затем отыскать его на зараженном компьютере. Ниже приводится несколько сове¬ 
тов, полезных для индивидуальных пользователей, а также обсуждаются действия, 
которые вся индустрия в целом может предпринять, чтобы значительно снизить 
остроту данной проблемы. 

Что могут сделать пользователи, чтобы избежать заражения вирусом? Во-пер¬ 
вых, выбрать операционную систему, предоставляющую определенный уровень 
защиты, со строгим разграничением режимов работы ядра и пользователя, а также 
раздельными паролями регистрации для каждого пользователя и системного адми¬ 
нистратора. При таких условиях, даже если какой-либо пользователь случайно за¬ 
несет вирус в систему, этот вирус не сможет заразить системные двоичные файлы. 

Во-вторых, устанавливайте только архивированное программное обеспечение, 
приобретенное у надежного производителя. Хотя даже зто не гарантирует стопро¬ 
центного отсутствия вирусов, так как были случаи, когда рассерженные сотруд¬ 
ники фирмы распространяли вирусы в коммерческом программном обеспечении, 
тем не менее это значительно помогает. Загрузка программного обеспечения с веб¬ 
сайтов и ВВ5 весьма рискованна. 

В-третьих, приобретите хорошее антивирусное программное обеспечение и ис¬ 
пользуйте его так, как написано в инструкции. Обязательно получайте регуляр¬ 
ные обновления с \ѵеЬ-сайтов производителя. 

В-четвертых, не щелкайте мышью на присоединенных к электронным письмам 
файлах и скажите, чтобы вам не присылали такие файлы. Электронная почта 
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в виде простого А5СІІ- текста всегда безопасна, но вложенные файлы могут быть 
опасны. 

В-пятых, архивируйте почаще ключевые файлы на внешних носителях, таких 
как гибкие диски, СЭК. или на магнитной ленте. Храните несколько последова¬ 
тельных версий каждого файла на разных внешних дисках. Тогда, если вы обнару¬ 
жите вирус, у вас появляется шанс восстановить файлы. Заархивированный вчера 
уже зараженный файл не поможет, а вот версия недельной давности может ока¬ 
заться полезной. 

Компьютерная промышленность также должна серьезно относиться к вирусной 
угрозе и изменить некоторые свои схемы поведения, представляющие опасность. 
Во-первых, следует производить простые операционные системы. Чем больше в 
операционной системе всяких прибамбасов, тем больше дыр в системе безопасно¬ 
сти. Это медицинский факт. 

Во-вторых, не применяйте активное содержимое документов. С точки зрения 
безопасности это катастрофа. Для просмотра присланного видеосервером доку¬ 
мента не должна запускаться содержащаяся в документе программа. Например, 
ДРЕС-файлы не содержат программ и поэтому не могут содержать вирусов. Все 
документы должны работать подобным образом. 

В-третьих, должен быть способ избирательно устанавливать защиту записи на 
цилиндры определенного диска, чтобы вирусы не могли заразить программы, хра¬ 
нящиеся в этих цилиндрах. Подобная защита может быть реализована с помощью 
битового массива в контроллере, в котором перечисляются все защищенные ци¬ 
линдры. Изменение содержимого этого битового массива должно разрешаться 
только тогда, когда пользователь переключил механический переключатель на 
передней панели компьютера. 

В-четвертых, флэш-ПЗУ представляет собой прекрасную идею, но запись в него 
также должна разрешаться только при определенном положении механического 
переключателя, что может сделать пользователь, устанавливая новую версию ВЮ5. 
Само собой, ни одно из этих предложений не будет восприниматься всерьез, пока 
действительно большой жареный вирусный петух нас всех не клюнет. Например, 
обнулив все банковские счета во всем мире. Хотя тогда что-либо предпринимать 
будет уже поздно. 

Восстановление после вирусной атаки 

При обнаружении вируса компьютер следует немедленно остановить, так как 
резидентный вирус может все еще работать. Компьютер следует перезагрузить 
с СЭ-КОМ или гибкого диска, на котором всегда должна быть установлена защи¬ 
та от записи. На этом диске должна содержаться полная операционная система, 
чтобы не использовать при загрузке жесткий диск с его загрузочным сектором, 
копией операционной системы и драйверами, которые могут быть инфицирова¬ 
ны. Затем с оригинального СЭ-КОМ следует запустить антивирусную програм¬ 
му, так как версия программы, хранящаяся на жестком диске, также может быть за¬ 
ражена. 

Антивирусная программа может обнаружить некоторые вирусы и может даже 
устранить их, но нет никакой гарантии, что она найдет их все. Вероятно, самый 
надежный метод заключается в том, чтобы сохранить на внешнем носителе все 
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файлы, которые не могут содержать вирусов (например, А5СІІ и ДРЕС-файлы). 
Те файлы, которые моіуг содержать вирусы (например, документы редактора \ѴопІ), 
должны быть преобразованы в другой формат, который не может содержать виру¬ 
сы, скажем, в текст А5СІІ (или, по крайней мере, следует удалить все макросы). 
Затем жесткий диск следует переформатировать программой форматирования, 
загруженной с защищенного от записи гибкого диска или СЭ-К.ОМ, чтобы гаран¬ 
тировать, что сама программа форматирования не заражена вирусом. Особенно 
важно, чтобы главная загрузочная запись и загрузочные секторы были полностью 
стерты. Затем следует переустановить операционную систему с оригинального 
СО-ПОМ. Когда вы имеете дело с вирусом, не бойтесь прослыть параноиком. 

Интернет-черви 

Первый случай масштабного прорыва системы безопасности компьютеров, подклю¬ 
ченных к Интернету, произошел 2 ноября 1988 года, когда аспирант университета 
Корнелла в штате Нью-Йорк Роберт Таппан Моррис выпустил написанного им 
червя в Интернет. В результате этого действия были заражены тысячи компьюте¬ 
ров в университетах, корпорациях и правительственных лабораториях по всему 
миру, прежде чем эту программу удалось выследить и удалить. Кроме того, ре¬ 
зультатом этих событий явился спор, не стихающий до сих пор. Мы обсудим ниже 
подробности этих событий. Дополнительные технические подробности описаны 
в [310]. Та же история, но в жанре полицейского триллера рассказана в [141]. 

История началась с того, что 1988 году Моррис обнаружил две ошибки в опе¬ 
рационной системе Вегкіеу ИШХ, позволяющие получить несанкционированный 
доступ к компьютерам по всему Интернету. В одиночку он написал самораз¬ 
множающуюся программу, называемую червем, использующую эти ошибки и в те¬ 
чение секунд реплицирующую себя на каждой машине, к которой ей удается по¬ 
лучить доступ. Он работал над этой программой несколько месяцев, тщательно 
настраивая ее и пытаясь научить программу заметать следы. 

Неизвестно, была ли версия от 2 ноября 1988 года тестовой или окончатель¬ 
ной. В любом случае она поставила на колени большинство систем Зип н ѴАХ по 
всему Интернету за какие-то несколько часов после попадания в сеть. Мотивация 
Морриса не ясна, хотя он, возможно, предполагал всего лишь пошутить, но в резуль¬ 
тате программной ошибки ситуация вышла из-под контроля. 

Технически червь состоял из двух программ: начального загрузчика и собствен¬ 
но червя. Начальный загрузчик представлял собой 99 строк на языке С (файл на¬ 
зывался И.с). Этот загрузчик компилировался и исполнялся на атакуемом компь¬ 
ютере. Будучи запущенным, он связывался с машиной, с которой был загружен, 
загружал основного червя и запускал его. После некоторых действий, направлен¬ 
ных на попытки скрыть свое существование, червь заглядывал в таблицы марш¬ 
рутизации нового хоста, определяя компьютеры, с которыми был соединен хост, 
после чего пытался распространить начальный загрузчик на эти машины. 

Для инфицирования новых машин применялись три метода. Метод 1 заключал¬ 
ся в попытке запустить удаленную оболочку при помощи команды гзк. Некоторые 
компьютеры доверяют другим компьютерам и позволяют запускать гзк, не требуя 
никакой аутентификации. Если это срабатывало, удаленная оболочка загружала 
червя и продолжала заражать новые машины. 
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Метод 2 использовал программу, присутствующую на всех системах ВЗБ, на¬ 
зываемую /іп§ег. Она позволяет пользователю в Интернете ввести команду 

Гіпдег пашеѲзіТе 

чтобы отобразить информацию о владельце или администраторе конкретного 
компьютера. Эта информация обычно включает физическое имя, регистрацион¬ 
ное имя, домашний адрес, телефон, имя и номер телефона секретаря, номер факса 
и т. д. То есть это электронный эквивалент телефонной книги. 

фоновый процесс, называющийся Гт§ег сіаешоп, отвечая на запросы, поступающие 
со всего Интернета. Червь обращался к программе /іп§ег со специально разработан¬ 
ной 536-байтовой строкой в качестве параметра. Эта строка вызывала переполне¬ 
ние буфера демона и попадала в его стек, как было показано на рис. 9.6, в. В данном 
случае использовалось отсутствие проверки на переполнение буфера. Когда про¬ 
цедура демона возвращала управление, она попадала не в головной модуль, а в про¬ 
цедуру, находящуюся внутри 536-байтовой строки в стеке. Эта процедура пыталась 
запустить программу зк. Если это ей удавалось, червь получал оболочку, работаю¬ 
щую на атакуемой машине. 

Метод 3 использовал ошибку в почтовой системе зепеітаіі, позволявшей червю 
послать по почте копию начального загрузчика и запустить его. 

Попав в систему, червь пытался взломать систему паролей. Для этого Моррису 
не понадобилось предпринимать собственных исследований. Все, что ему по¬ 
требовалось, — это попросить у собственного отца, эксперта в области безопасности 
в Управлении национальной безопасности США, профессионально занимающем¬ 
ся взломом кодов, перепечатку классической статьи, написанной десятилетием 
раньше Моррисом старшим и Кеном Томпсоном в лаборатории Веіі ЬаЬз [240]. 
Каждый взломанный пароль позволял червю зарегистрироваться на любой маши¬ 
не, на которой у владельца пароля были учетные записи. 

Каждый раз, когда червь получал доступ к новой машине, он проверял, есть ли 
уже другие активные копии червя на этой машине. Если червь уже был на этой 
машине, то новая копия прекращала свою деятельность, кроме одного случая из 
семи, в котором она продолжал работать, чтобы червь мог продолжать распрост¬ 
раняться, даже если системный администратор запустил свою версию червя, что¬ 
бы обмануть настоящего червя. Использование соотношения 1 к 7 оказалось слиш¬ 
ком большим и привело к тому, что зараженные машины настолько заполнились 
червями, что просто не могли работать. Если бы Моррис не делал исключений для 
каждого седьмого случая, червь, возможно, до сих пор жил бы в Интернете, никем 
не обнаруженный. 

Морриса поймали, когда один из его друзей разговаривал с репортером из 
компьютерной редакции Нью-Йорк Таймс, Джоном Марковым, и пытался убедить 
репортера, что все это лишь несчастный случай, что червь безобиден и автор весь¬ 
ма сожалеет. Друг по неосторожности упомянул, что регистрационное имя нару¬ 
шителя гіт. Преобразовать Нт в физическое имя владельца было несложно — все, 
что Маркову надо было сделать, — это запустить процедуру /іп§ег. На следующий 
день эта история оказалась на первых полосах всех газет, вытеснив оттуда даже 
информацию о предстоящих через три дня президентских выборах. 
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Моррис предстал перед федеральным судом и был приговорен к штрафу в раз¬ 
мере 10 000 долларов, трем годам испытательного срока и 400 часам общественных 
работ. Его судебные издержки, вероятно, превысили 150 000 долларов. Приговор 
породил множество разногласий. В компьютерном обществе многие считали, что 
Моррис был блестящим студентом, чья опасная шалость вышла из-под контроля. 
Написанная им программа не содержала ничего, что бы свидетельствовало о наме¬ 
рениях Морриса украсть какие-либо данные или причинить какой-либо намерен¬ 
ный ущерб. Другие считали его серьезным преступником, которому место в тюрьме. 

Одним из результатов этого инцидента было создание группы компьютерной 
«скорой помощи» СЕКТ (Согариіег Егаег§епсу Кгезропзе Теага), основными зада¬ 
чами которой являются доклады о попытках взлома в Интернете, а также анализ 
проблем безопасности и разработка методов их решения. При необходимости эта 
группа рассылает свою информацию тысячам системных администраторов по 
Интернету. К сожалению, этой информацией, содержащей сообщения об ошибках 
в системах, могут воспользоваться также и злоумышленники (возможно, притво¬ 
ряющиеся системными администраторами) и использовать часы (или даже дни), 
требующиеся на устранение обнаруженных ошибок. 


Мобильные программы 

Вирусы и черви представляют собой программы, попадающие на компьютер без 
ведома владельца компьютера и вопреки его желанию. Однако иногда пользова¬ 
тели импортируют и запускают чужие программы на своем компьютере более или 
менее намеренно. Как правило, это происходит следующим образом. В далеком 
прошлом (что в мире Интернета означает в прошлом году) большинство \ѵеЬ- 
страниц представляли собой статичные НТМЕ-файлы с несколькими связанны¬ 
ми с ними изображениями. Сегодня все большее число \ѵеЬ-страниц содержат про¬ 
граммы, называемые апплетами. Когда загружается \ѵеЬ-страница, содержащая 
апплеты, апплеты скачиваются на компьютер и выполняются. Например, апплет 
может содержать форму, которую следует заполнить, с интерактивной справочной 
системой, помогающей при ее заполнении. Когда форма заполнена, она может быть 
отправлена куда-либо по Интернету на обработку. Эта технология может приме¬ 
няться для заполнения налоговых деклараций, заказа товаров и т. д. 

Другой пример программ, переносимых с одной машины на другую для выпол¬ 
нения на удаленной машине, представляют собой агенты. Это программы, запус¬ 
каемые пользователем для выполнения определенной задачи и сообщения резуль¬ 
тата. Например, агента можно попросить найти на \ѵеЬ-сайтах путешествий самый 
дешевый рейс от Амстердама до Сан-Франциско. Прибывая на каждый сайт, агент 
запускается на нем, собирает требуемую информацию и перемещается на следую¬ 
щий \ѵеЬ-сайт. Выполнив свою работу, он может вернуться и доложить о собран¬ 
ных им сведениях. 

Третий пример мобильной программы — это файл в формате РозіЗсгірі, кото¬ 
рый должен быть распечатан на принтере, поддерживающем этот формат. Файл 
в формате РозіЗсгірі в действительности представляет собой программу на языке 
программирования РозіЗсгірі, исполняющуюся внутри принтера. Обычно эта про¬ 
грамма велит принтеру начертить определенные кривые линии, а затем заполнить 
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их каким-либо цветом, но она может также выполнять и другие действия. Аппле¬ 
ты, агенты и файлы в формате РозіЗсгірГ — это всего лишь три примера мобиль¬ 
ных программ, однако существует еще множество других разновидностей мобиль¬ 
ных программ. 

С учетом приведенного выше долгого обсуждения вирусов и червей должно 
быть ясно, что позволять чужой программе работать на вашей машине несколько 
рискованно. Тем не менее многим хотелось бы иметь возможность запускать эти 
чужие программы. Так возникает вопрос: «Можно ли запускать мобильные програм¬ 
мы безопасно?» Краткий ответ на этот вопрос звучит так: «Да, но это нелегко». Фун¬ 
даментальная проблема заключается в том, что процесс импортирует апплет или 
другую мобильную программу в свое адресное пространство и исполняет ее. Импор¬ 
тированная программа работает как часть пользовательского процесса и обладает 
всеми полномочиями, которыми обладает пользователь, включая возможность 
читать, писать, удалять или зашифровывать файлы пользователя на жестком дис¬ 
ке, посылать данные по электронной почте в дальние страны и многое другое. 

Давным-давно в операционных системах была разработана концепция процес¬ 
сов, чтобы отгородить пользователей друг от друга. Идея заключается в том, что 
у каждого пользователя есть свое адресное пространство и свой идентификатор 
ИГО, что позволяет ему получать доступ к файлам и другим ресурсам, принадле¬ 
жащим ему, но не другим пользователям. Защиты ресурсов и одной части процес¬ 
са от другой части процесса (апплета) концепция процесса предоставить не мо¬ 
жет. Концепция потоков обеспечивает возможность параллельного исполнения 
нескольких задач в одном адресном пространстве процесса, но не предоставляет 
никакой защиты одного потока от другого. 

Теоретически запуск каждого апплета в виде отдельного процесса может не¬ 
сколько помочь, но часто оказывается невыполнимым. Например, \ѵеЬ-страница 
может содержать два или более апплетов, взаимодействующих друг с другом, а так¬ 
же с данными \ѵеЬ-страницы. \ѴеЬ-браузеру может также понадобиться взаимо¬ 
действовать с апплетами, запуская и останавливая их, снабжая их данными и т. д. 
Если каждый апплет поместить в свой собственный процесс, все это не сможет 
работать. Более того, помещение каждого апплета в свое собственное адресное про¬ 
странство нисколько не усложняет апплету кражу информации или причинение 
ущерба. 

Были предложены и реализованы новые разнообразные методы работы с аппле¬ 
тами (и мобильными программами в целом). Ниже мы рассмотрим три из этих 
методов: «песочницы», интерпретацию и программы с подписями. У каждого мето¬ 
да есть свои достоинства и недостатки. 

«Песочницы» 

Первый метод, метод «песочниц», представляет собой попытку установить для 
апплета во время исполнения ограниченный диапазон виртуальных адресов [349]. 
Суть метода состоит в том, что виртуальное адресное пространство делится на обла¬ 
сти равного размера, называемые «песочницами». Обязательным свойством каждой 
песочницы является одинаковость старших разрядов адресов в пределах одной 
песочницы. Так, 32-разрядное адресное пространство может быть разделено на 
256 песочниц, разделенных границами адресов, кратных 16 Мбайт; таким образом, 




Атаки системы снаружи 


701 


у всех адресов в пределах одной песочницы будут одинаковые верхние 8 бит. С тем 
же успехом данное адресное пространство можно разделить на 512 песочниц по 
8 Мбайт, в этом случае каждая песочница получает 9-разрядный адресный пре¬ 
фикс. Размер песочницы следует выбирать так, чтобы в нее помещался самый 
большой апплет, но при этом так, чтобы не тратить на апплеты слишком много 
виртуального адресного пространства. Физическая память не является проблемой, 
если замещение страниц по требованию присутствует, а оно, как правило, присут¬ 
ствует. Каждому апплету выделяется две песочницы, одна для программы и одна 
для данных, как показано на рис. 9.11 для случая 16 песочниц по 16 Мбайт. 

Виртуальный 
адрес в мегабайтах 


Монитор обращений 
для проверки системы 

МО ѴК1, 51 
5НК #24, 51 
СМР 51, 52 
ТКАРЫЕ 
змр (К1) 

^ Апплет 2 


^ Апплет 1 

а б 

Рис. 9.11. Память, разделенная на 16 песочниц по 16 Мбайт 

Основная идея песочниц заключается в гарантировании, что апплет не сможет 
передать управление программе за пределами песочницы или обратиться к дан¬ 
ным вне ее. Две песочницы выделяются для того, чтобы апплет не смог модифи¬ 
цировать свою собственную программу во время исполнения, обходя данные ог¬ 
раничения. Запретом изменения песочницы, содержащей программу, устраняется 
опасность самомодифицирующихся программ. Пока апплет ограничивается по¬ 
добным образом, он не может причинить ущерб браузеру или другим апплетам, 
установить вирусы в памяти или еще каким-либо способом повредить память. 

Как только апплет загружен, он настраивается на работу по предоставляемым 
ему адресам песочниц. Затем выполняется проверка ограниченности всех адрес¬ 
ных ссылок пределами соответствующей песочницы. Ниже мы будем рассматри¬ 
вать только ссылки на программу (то есть команды перехода ЛІР и САП), но то же 
самое справедливо для обращений к данным. Статические команды ЗМР, использую¬ 
щие прямую адресацию, проверить легко. Не намного сложнее проверить команды 
передачи управления, использующие относительную адресацию. Если обнаружи¬ 
вается, что апплет собирается предпринять попытки выскочить за пределы своей 
песочницы, он просто отвергается и не запускается. Аналогично проверяются об¬ 
ращения к данным. 
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Труднее проверить команды, использующие косвенную адресацию, например 
динамические команды ЗМР. У большинства машин есть команда, передающая 
управление по адресу, содержащемуся в каком-либо регистре, значение которого 
вычисляется во время исполнения программы, например .1МР (К1). Допустимость 
такой команды можно проверить во время исполнения. Для этого непосредственно 
перед выполнением этой команды прямо в код программы помещается несколько 
команд, сравнивающих содержимое этого регистра с границами песочницы. При¬ 
мер такой проверки приведен в листинге 9.6. Как вы помните, у всех допустимых 
адресов должны быть одинаковые старшие к бит. Префикс можно хранить в реги¬ 
стре, например, 52. Этот регистр не должен использоваться апплетом, для чего, воз¬ 
можно, потребуется переписать весь апплет 1 . 

Листинг 9.6. Один из способов проверки допустимости команды 

МОѴ К1. 51 
5НР #24. 51 
СМР 51. 52 
ТКАРИЕ 
1МР (Ш 

Программа работает следующим образом. Сначала исследуемый адрес копиру¬ 
ется во вспомогательный регистр 51. Затем этот регистр сдвигается вправо, в резуль¬ 
тате чего в регистре получается значение префикса песочницы. Затем вычислен¬ 
ное таким образом значение сравнивается с эталоном, хранящимся в регистре 52. 
Если они не совпадают, происходит эмулированное прерывание и апплет уничто¬ 
жается. Для проверки требуется четыре команды и два вспомогательных регистра. 

Для установки подобных вставок в двоичную программу во время ее выполне¬ 
ния требуются определенные усилия, но ничего невыполнимого в этом нет. Было 
бы значительно проще, если бы апплеты поступали в виде исходных текстов, а за¬ 
тем компилировались локально доверенным компилятором, автоматически про¬ 
веряющим статические адреса и вставляющим необходимые команды для провер¬ 
ки динамических адресов. В том и другом случае накладные расходы по проверке 
динамических адресов составляют всего около 4 %, что вполне приемлемо [349]. 

Вторая проблема заключается в системных вызовах, к которым пытается обра¬ 
щаться апплет. Решается эта проблема следующим образом. Каждый системный вы¬ 
зов в апплете заменяется вызовом специального модуля, называемого монитором 
обращений. Делается это на том же проходе, на котором вставляются макросы про¬ 
верки динамических адресов (или если доступен исходный текст, то при компонов¬ 
ке апплета может использоваться специальная библиотека, обращающаяся к мони¬ 
тору обращений, вместо системных вызовов). В любом случае монитор обращений 
изучает каждую попытку системного вызова и решает, безопасно ли его выполне¬ 
ние. Если известно, что обращение к данному системному вызову может быть опас¬ 
но или же монитор обращений в обратном не уверен, апплет уничтожается. Если 
монитор обращений способен определить, какой апплет к нему обратился, то может 
использоваться один общий монитор, обслуживающий запросы ото всех апплетов. 
Разрешения монитору обращений, как правило, задаются в файле конфигурации. 


1 Чем выделять на это целый регистр, да еще переписывать апплет, гораздо проще сравнивать регистр 51 
с константой. — Примеч. перев. 
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Интерпретация 

Второй способ выполнения апплетов, которым нельзя доверять, заключается в том, 
что апплету не передается управление, а вместо этого его шаг за шагом выполняет 
интерпретатор. Этот метод применяется \ѵеЬ-браузерами. Апплеты \ѵеЬ-страниц 
обычно пишутся на языке^ѵа, представляющем собой нормальный язык програм¬ 
мирования, либо на высокоуровневом языке сценариев, например заІе-ТСЬ или 
^ѵазсгірі. Апплеты ^ѵа сначала компилируются в виртуальный машинный стек- 
ориентированный язык, называемый ДѴМ 1 Уаѵа Ѵігіиаі МасЬіпе — виртуальная 
машина ^ѵа). Именно эти .ІѴМ-апплеты помещаются в \ѵеЪ-страницы. После 
загрузки они помещаются в .ІѴМ-интерпретатор, содержащийся в браузере, как 
показано на рис. 9.12. 


Виртуальное 
адресное пространство 


ОхРРРРРРРР 


Песочница 

Интерпретатор 


0 



ѴѴеЬ-браузер 


Апплет, которому не доверяют 


Доверенный апплет 


Рис. 9.12. Апплеты могут интерпретироваться ѵѵеЬ-браузером 


Преимущество использования интерпретируемой программы перед исполня¬ 
емой заключается в том, что каждая команда программы перед исполнением 
изучается интерпретатором. Это дает интерпретатору возможность проверить 
допустимость адресов. Кроме того, системные вызовы также перехватываются и 
интерпретируются. Обработка этих системных вызовов зависит от применяемой 
политики безопасности. Например, если апплету можно доверять (предположим, 
он поступил с локального диска), его системные вызовы могут выполняться без 
лишних вопросов. Однако если апплету доверять нельзя (скажем, если он пришел 
по Интернету), он может быть помещен в песочницу, чтобы ограничить его воз¬ 
можности. 

Программы, написанные на высокоуровневых языках сценариев, также могут 
интерпретироваться. В этом случае машинные адреса не используются, поэтому 
нет опасности, что сценарий попытается получить доступ к памяти недопустимым 
образом. Недостаток интерпретации в основном состоит в том, что такой метод 
исполнения программ значительно медленнее по сравнению с исполнением отком¬ 
пилированных программ. 


Точнее, 1ѴМ — это не язык, а нечто вроде операционной системы. Так называется сам интерпретатор, 
выполняющий апплеты Іаѵа. — Примеч. перев. 
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Программы с подписями 

Еще один способ обеспечения безопасности исполнения апплетов заключается в том, 
что клиент знает, откуда пришел апплет, и запускает только апплеты от доверенных 
источников. При таком подходе пользователь может содержать список доверенных 
поставщиков апплетов и запускать апплеты только этих поставщиков. Апплеты 
ото всех остальных источников отвергаются как ненадежные. При таком подходе 
никаких механизмов обеспечения безопасности во время исполнения не использу¬ 
ется. Апплеты от доверенных поставщиков запускаются в том виде, в котором они 
получены, а все остальные апплеты не запускаются вообще, либо запускаются в стре¬ 
ноженном виде (с помощью песочниц или интерпретации с ограниченным досту¬ 
пом или вообще без доступа к файлам пользователя и другим системным ресурсам). 

Чтобы такая схема работала, у пользователя как минимум должен быть способ 
определить, что апплет был написан производителем, которому можно доверять, 
и не изменен кем-либо еще впоследствии. Это может реализовываться при помо¬ 
щи цифровых подписей. 

Для цифровых подписей используется шифрование с открытым ключом. Про¬ 
изводитель апплета, как правило компания, занимающаяся производством про¬ 
граммного обеспечения, создает пару (открытый ключ, закрытый ключ), публи¬ 
кует открытый ключ и тщательно охраняет закрытый. Чтобы подписать апплет, 
производитель сначала вычисляет хэш-код апплета, 128-разрядный или 160-разряд - 
ный, в зависимости от используемого алгоритма (МО 5 или 5НА). Затем хэш-код 
зашифровывается (или «расшифровывается», если применять нотацию рис. 9.2). 
Эта подпись сопровождает апплет, куда бы тот ни направлялся. 

Когда пользователь получает апплет, браузер вычисляет значение хэш-функции. 
Затем он расшифровывает открытым ключом прилагающуюся подпись и сравни¬ 
вает два хэш-кода. Если они совпадают, апплет принимается. В противном случае 
он считается подделкой. Используемая математика делает крайне сложной под¬ 
делку апплета или подписи, если не известен закрытый ключ. Процесс формиро¬ 
вания и проверки подписи проиллюстрирован на рис. 9.13. 


Производитель 

программного 

обеспечения Пользователь 



Рис. 9.13. Принцип работы цифровой подписи 




Атаки системы снаружи 
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Безопасность в системе иаѵа 

Язык программирования^ѵа и соответствующая интерпретирующая система были 
разработаны, чтобы можно было один раз написать и откомпилировать программу, 
которая потом могла бы загрузиться по Интернету и выполниться на любой маши¬ 
не, поддерживающей ^ѵа. Безопасность являлась частью системы ^ѵа с самого на¬ 
чала. В данном разделе будут описаны принципы работы системы безопасности ^ѵа. 

Заѵа представляет собой язык программирования, обеспечивающий типовую 
безопасность. Это означает, что компилятор отвергнет любые попытки использо¬ 
вать переменную каким-либо способом, несовместимым с ее типом. Для сравне¬ 
ния рассмотрим пример программы на языке С: 

паидМ;у_Гипс() 

{ 

сЬаг *р; 
р = гапсК); 

*р = 0: 

} 

Эта функция формирует псевдослучайное число (целое) и сохраняет его в ука¬ 
зателе на байтовый массив р'. Затем по новому адресу, содержащемуся в перемен¬ 
ной/?, перезаписывается все, что там было, программа или данные. В языке Заѵа 
конструкции, смешивающие типы подобным образом, запрещены на уровне грам¬ 
матики. Кроме того, в языке Заѵа нет переменных указателей, преобразования 
типов, управляемых пользователем процедур выделения памяти (таких, как таііос 
и/гее), а обращения к массивам проверяются во время исполнения программы. 

Программы на языке ^ѵа компилируются в двоичный код, называемый ДѴМ- 
кодом Оаѵа Ѵігіиаі МасЬіпе — виртуальная машина іаѵа). В этом коде около 
100 команд, большая часть которых помещает объекты определенного типа в стек, 
достает их из стека или выполняет с объектами, хранящимися в стеке, арифме¬ 
тические действия. Как правило, эти программы интерпретируются, хотя в неко¬ 
торых случаях они могут компилироваться в машинный код для более быстрого 
исполнения. В модели ^ѵа апплеты, посылаемые по Интернету для удаленного 
выполнения, являются 3 ѴМ -программами. 

Когда апплет прибывает, он пропускается сквозь процедуру, проверяющую, удов¬ 
летворяет ли апплет определенным правилам. Откомпилированный соответствую¬ 
щим образом апплет автоматически подчиняется этим правилам, ничто не мешает 
злоумышленнику написать ^М-апплет на_|УМ-ассемблере. В проверку входит: 

1. Пытается ли апплет подделать указатели? 

2. Нарушает ли он ограничения доступа к закрытым членам классов? 

3. Пытается ли он использовать переменную одного типа как переменную дру¬ 
гого типа? 

4. Не переполняет ли апплет стек и не пытается ли он переместить указатель 
стека за его предельные границы? 

5. Не преобразует ли он незаконно переменные из одного типа в другой? 


1 Такое было возможно, но только в очень древнем компиляторе С. В Ѵізиаі С++ 5-Й и 6-й версий 
компилятор откажется транслировать такую программу, требуя явного преобразования типов. — 
Примеч. перев. 
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Если апплет проходит все тесты, его можно смело запускать, не опасаясь, что 
он обратится к области памяти за пределами апплета. 

Однако апплеты могут обращаться к системным вызовам, вызывая методы 
(процедуры) ]аѵа, предоставленные для этой цели. В первой версии системы ]аѵа, 
1.0 Оаѵа Эеѵеіортепі: Кіі — инструментальный комплект поддержки разра¬ 
боток в среде ^ѵа), апплеты подразделялись на два класса: доверенные и те, кото¬ 
рым доверять нельзя. Апплеты, загружаемые с локального диска, считались дове¬ 
ренными, и им позволялось обращаться к любым системным вызовам. К апплетам, 
загружаемым из Интернета, напротив, относились с недоверием. Эти апплеты по¬ 
мещались в песочницы, как показано на рис. 9.12, и им практически ничего не раз¬ 
решалось делать. 

Поэкспериментировав некоторое время с этой моделью, корпорация 5ип пришла 
к выводу, что она слишком сильно ограничивает возможности апплетов. В пакете 
1.1 были использованы электронные подписи. Когда апплет прибывал по 
Интернету, виртуальная машина ]аѵа проверяла, был ли он подписан человеком 
или организацией, которой пользователь доверял (что указывалось пользователем 
в списке доверенных поставщиков апплетов). Если у апплета была соответству¬ 
ющая подпись, ему разрешалось выполнение. В противном случае он помещал¬ 
ся в песочницу со строгими ограничениями. 

Получив больше опыта, корпорация 5ип убедилась, что этих мер защиты также 
недостаточно, поэтому модель безопасности была снова изменена. Пакет 1.2 
предоставляет возможность детальной настройки политики безопасности, приме¬ 
нимой ко всем апплетам, как к локальным, так и к удаленным. Модель безопаснос¬ 
ти, применяемая в данном пакете, настолько сложна, что ей может быть посвяще¬ 
на отдельная книга [131], поэтому здесь мы ограничимся кратким перечислением 
наиболее ярких моментов. 

Каждый апплет характеризуется двумя параметрами: откуда он пришел и кто 
его подписал. Откуда он пришел, указано в его ИКЬ-указателе. Каждый пользова¬ 
тель может создать политику безопасности, состоящую из набора правил. В пра¬ 
виле могут перечисляться ІЛІЕ-указатель, владелец подписи, объект и действие, 
которые апплету разрешается выполнять с этим объектом, если ШП. и владелец 
подписи соответствуют указанным в правиле. Пример информации, содержащей¬ 
ся в правиле, продемонстрирован в табл. 9.3, хотя фактическая форма представле¬ 
ния этих данных может быть другой и относится к иерархии классов ]аѵа. 


Таблица 9.3. Несколько примеров политик безопасности пакета ЗЭК 1.2 


ІІШ- 

Владелец подписи 

Объект 

Действие 

ѵѵѵѵѵѵДахргер . сот 

ТахРгер 

/изг/зизап/1 040.ХІЗ 

Чтение 

* 


/изг/ітр /* 

Чтение,запись 

ѵѵѵѵѵѵ. ті сгозоД. сот 

МісгозоД 

/изг/зизап/ОДІ се/- 

Чтение, запись, удаление 


Действия с объектами могут включать доступ к файлам. Действие может указы¬ 
вать конкретный файл или каталог, все файлы в заданном каталоге или все файлы 
и каталоги, содержащиеся в данном каталоге. Этим трем случаям соответствуют 
три строки в табл. 9.3. В первой строке пользователь Сьюзан разрешила чтение 





Механизмы защиты 
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файла 1040лЬ для апплетов, загружающихся с машины ѵѵѵѵѵѵАахргер.сот, принад¬ 
лежащей компании ТахРгер и подписанных этой компанией. Это единственный 
файл, который разрешается читать этому апплету, и никакой другой апплет не 
может читать этот файл. Кроме того, всем апплетам, подписанным или нет, разре¬ 
шается читать и писать файлы в каталоге /изг/ітр. 

Сьюзан также настолько доверяет корпорации Місгозой, что позволяет всем 
апплетам с сайта этой компании читать, писать и удалять все файлы в каталоге 
0//ісе со всеми его подкаталогами, например, чтобы исправлять ошибки или уста¬ 
навливать новые версии программного обеспечения. Для проверки подписей Сью¬ 
зан нужно либо иметь все необходимые открытые ключи на своем диске, либо она 
должна получать их динамически, например, в виде сертификатов, подписанных 
компанией, которой она доверяет и чьи открытые ключи у нее уже есть. 

Защищаться могут не только файлы. Доступ к сети также может быть защи¬ 
щен. Объектами в данном случае являются определенные порты или конкретные 
компьютеры. Компьютер указывается ІР-адресом или ОК т 5-именем. Порты на этой 
машине указываются в виде диапазона чисел. К возможным действиям относятся 
запрос соединения с удаленной машиной и прием соединений, исходящих от 
удаленного компьютера. Таким образом, апплету может быть предоставлен сете¬ 
вой доступ, ограниченный списком указанных компьютеров и портов. Апплеты 
могут динамически подгружать дополнительные программы (классы), но пре¬ 
доставляемые пользователем загрузчики классов имею право указывать, с каких 
машин данные классы моіут быть загружены. Имеется и множество других настра¬ 
иваемых параметров безопасности. 


Механизмы защиты 

В предыдущих разделах мы рассмотрели множество проблем, некоторые из них 
были техническими, тогда как другие — нет. В следующих разделах мы сконцент¬ 
рируемся на некоторых технических деталях методов защиты файлов, используе¬ 
мых в операционных системах. Во всех этих методах проводится четкое разграни¬ 
чение между политикой (от кого и чьи данные должны защищаться) и механизмом 
(как система проводит данную политику). Отделение политики от механизма об¬ 
суждается в [289]. Мы уделим особое внимание именно механизму, а не политике. 

В некоторых системах защита реализуется при помощи программы, называю¬ 
щейся монитором обращений. При каждой попытке доступа к некоторому ресурсу 
система сначала просит монитор обращений проверить законность данного досту¬ 
па. Монитор обращений смотрит в таблицы политики и принимает решение. Ниже 
будет описано окружение, в котором работает монитор обращений. 


Домены защиты 

Компьютерная система содержит множество «объектов», которые требуется защи¬ 
щать. Это может быть аппаратура (например, центральный процессор, сегменты 
памяти, диски или принтеры) или программное обеспечение (например, процес¬ 
сы, файлы, базы данных или семафоры). 
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У каждого объекта есть уникальное имя, по которому к нему можно обращаться, 
и набор операций, которые моіут выполнять с объектом процессы. Так, с файлом мо- 
гут выполняться операции геасі и мгі іе, с семафором имеют смысл операции ир и сіоѵѵп. 

Очевидно, что для ограничения доступа к объектам требуется определенный 
механизм. Более того, этот механизм должен предоставлять возможность не пол¬ 
ного запрета доступа, а ограничения в пределах подмножества разрешенных опе¬ 
раций. Например, процессу Л может быть разрешено читать, но не писать файл Р. 

Чтобы обсудить различные механизмы защиты, полезно ввести концепцию до¬ 
мена. Домен представляет собой множество пар (объект, права доступа). Каждая 
пара указывает объект и некоторое подмножество операций, которые могут быть 
с ним выполнены. Права доступа означают в данном контексте разрешение вы¬ 
полнить одну из операций. Домен может соответствовать одному пользователю 
или группе пользователей. 


Домен 1 


Домен 2 Домен 3 




Файл 3 [К] 

Файл 4 [КѴѴХ](принтер 
Файл 5 [КѴѴ] ѵ 


Рис. 9.14. Три домена защиты 

На рис, 9.14 показаны три домена, содержащие объекты и разрешения [К\УХ — 
Кеаб, ЛѴгіСе, еХесиСе — чтение, запись выполнение] для каждого объекта. Обрати¬ 
те внимание, что объект Ргіпіегі одновременно присутствует в двух доменах. Хотя 
это и не изображено в данном примере, один и тот же объект может иметь в раз¬ 
личных доменах разные разрешения. 

В каждый момент времени каждый процесс работает в каком-либо одном доме¬ 
не защиты. Другими словами, имеется некоторая коллекция объектов, к которым 
он может получить доступ, и для каждого объекта у него есть определенный набор 
разрешений. Во время выполнения процессы имею право переключаться с одного 
домена на другой. Правила переключения между доменами в большой степени 
зависят от системы. 

Чтобы идея домена защиты выглядела более конкретно, рассмотрим пример из 
системы ІШІХ. В ІЖІХ домен процесса определяется его идентификаторами ІІГО 
и ОШ процесса. По заданной комбинации (ИГО, СГО) можно составить полный 
список всех объектов (файлов, включая устройства ввода-вывода, представленные 
в виде специальных файлов и т. д.), к которым процесс может получить доступ 
с указанием типа доступа (чтение, запись, исполнение). Два процесса с одной 
и той же комбинацией (ІІШ, СШ) будут иметь абсолютно одинаковый доступ к 
одинаковому набору объектов. 

Более того, каждый процесс в ІЖІХ состоит из двух частей: пользовательской 
части и системной части. Когда процесс обращается к системному вызову, он пе¬ 
реключается из пользовательской части в системную. Пользовательская и систем¬ 
ная части процесса имеют различный доступ к различным множествам объек¬ 
тов. Например, системная часть процесса может иметь доступ ко всем страницам 
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в физической памяти, ко всему диску и ко всем другим защищенным ресурсам. 
Таким образом, системный вызов осуществляет переключение доменов защиты. 

Когда процесс выполняет системный вызов ехес с файлом, у которого установ¬ 
лен бит 5ЕТШБ или 5ЕТСІБ, процесс может получить новые идентификаторы 
ШБ и СГО. При новой комбинации ШБ и СІБ процесс получает новый набор 
доступных файлов и операций. Запуск программы с установленным битом 5ЕТШБ 
или 5ЕТСІБ также представляет собой переключение домена, так как права дос¬ 
тупа при этом изменяются. 

Важным вопросом является то, как система отслеживает, какой объект какому 
домену принадлежит. Можно себе представить большую матрицу, в которой ря¬ 
дами являются домены, а колонками — объекты. На пересечении располагаются 
ячейки, содержащие права доступа для данного домена к данному объекту. Мат¬ 
рица для табл. 9.3 показана на рис. 9.15. При наличии подобной матрицы опера¬ 
ционная система может для каждого домена определить разрешения к любому за¬ 
данному объекту. 


Объект 


Домен 


Файл 1 Файл 2 Файл 3 Файл 4 Файл 5 Файл 6 Принтер 1 Плоттер 2 


1 

Чтение 

Чтение 

Запись 







2 



Чтение 

Чтение 

Запись 

Исполнение 

Чтение 

Запись 


Запись 


3 






Чтение 

Запись 

Исполнение 

Запись 

Запись 


Рис. 9.15. Матрица защиты 

Переключение между доменами также может быть легко реализовано при по¬ 
мощи все той же матрицы, если считать домены объектами, над которыми возмож¬ 
на операция епіег (вход). На рис. 9.16 снова изображена та же матрица, что и на 
предыдущем рисунке, но с тремя доменами, выступающими и в роли объектов. 
Процессы могут переключаться с домена 1 на домен 2, но обратно вернуться уже не 
могут. Эта ситуация моделирует выполнение программы с установленным битом 
5ЕТШБ в ІЖІХ. Другие переключения доменов в данном примере не разрешены. 


Домен 


Плоттер 2 Домен 2 


Файл 1 

Файл 2 

Файл 3 

Файл 4 

Файл 5 

Файл 6 Принтер 1 

Домен 1 


Домен 3 

Чтение 

Чтение 

Запись 








Епіег 




Чтение 

Чтение 

Запись 

Исполнение 

Чтение 

Запись 


Чтение 










Чтение 

Запись 

Исполнение 

Чтение 

Чтение 





Рис. 9.16. Матрица защиты с доменами в роли объектов 
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Списки управления доступом 

На практике, однако, разрешения доступа редко хранятся в виде матрицы, пока¬ 
занной на рис. 9.16, поскольку такая матрица была бы очень большой и практи¬ 
чески пустой. Поэтому, как правило, такие матрицы хранятся по рядам или столб¬ 
цам, причем хранятся только непустые элементы. Эти два подхода, как ни странно, 
различаются между собой. В данном разделе мы рассмотрим хранение матрицы 
•ааиэдш. таз сто зѵблтам., в разделе иъ\ тазжжошѵмся с. методом ее хране¬ 

ния по рядам. 

В первом методе с каждым объектом ассоциируется список (упорядоченный), 
содержащий все домены, которым разрешен доступ к данному объекту, а также тип 
доступа. Такие списки, называемые АСЬ-списками (Ассезз Сопігоі Ілві — список 
управления доступом), проиллюстрированы на рис. 9.17. Здесь мы видим три 
процесса, принадлежащих различным доменам А, В и С, а также три файла, Р\, Р2 
и Р 3. Для простоты мы будем предполагать, что каждому домену соответствует 
один пользователь, в данном случае А, В и С. Часто в литературе по информаци¬ 
онной безопасности пользователей называют субъектами или принципалами (вла¬ 
дельцами объектов), чтобы отличать их от объектов, которыми кто-то владеет. 


I Пространство 
{ пользователя 


к. Пространство 
Г ядра 


Рис. 9.17. Использование АСЬ-списков для управления доступом к файлам 


Процесс 



Владелец 




Файл 


Р1 


А: ВѴѴ; В: А 


Р2 


А: В; В:ВѴѴ; С:К 


АСЬ 


РЗ 


+4 В.КѴѴХ; С: КХ 


С каждым файлом связан АСЬ-список. У файла Р 1 в его АСЬ-списке есть три 
записи (разделенные символом точка с запятой). В первой записи утверждается, 
что любой процесс, которым владеет пользователь А, может читать и писать этот 
файл. Во второй записи говорится, что любой процесс, которым владеет пользо¬ 
ватель В, может читать этот файл. Все остальные типы доступа для данных 
пользователей запрещаются. Всем остальным пользователям запрещен любой до¬ 
ступ к этому файлу. Обратите внимание, что права предоставляются не процессу, 
а пользователю. Таким образом, любой процесс, которым владеет пользователь А, 
может читать и писать файл Р1. Не имеет значения, один такой процесс или их 100. 
Значение имеет идентификатор владельца, а не процесса. 

У файла Р2 в его АСЬ-списке есть три записи: пользователи А, В и С могут чи¬ 
тать файл, а пользователь В также может писать в него. Другие типы доступа не 
разрешаются. Файл РЗ, по-видимому, представляет собой исполняемую программу, 
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так как пользователи АиВ могут как читать, так и исполнять его. Пользователю В 
также разрешается писать в этот файл. 

Этот пример иллюстрирует самую общую форму защиты при помощи АСЬ- 
списков. Часто на практике используются более сложные системы. Начнем с того, 
что мы здесь показали только три типа доступа: чтение, запись и исполнение. Кро¬ 
ме них может быть еще много других типов доступа. Некоторые типы доступа мо¬ 
гут быть применимы ко всем объектам, например уничтожение или копирование 
объекта, а некоторые могут быть специфическими для определенных объектов. 
Примеры подобных разрешений: добавить сообщение для объекта почтовый ящик и 
сортировать в алфавитном порядке для объекта каталог. 

До сих пор мы рассматривали АСЬ-списки индивидуальных пользователей. 
Многими системами поддерживается концепция групп пользователей. У групп 
есть имена, и они также могут включаться в АСЬ-списки. Возможно применение 
двух вариантов семантики групп. В некоторых системах у каждого процесса есть 
идентификатор пользователя ИГО и идентификатор группы СГО. В других систе¬ 
мах АСЬ-списки содержат записи вида 

ШОІ.Сті: праваі: 0102.0102: права2; ... 

При такой схеме, когда к объекту поступает запрос доступа, выполняется про¬ 
верка с помощью ЫГО и СШ обращающегося с запросом процесса. Если они 
присутствуют в АСЬ-списке, то перечисленные в списке права предоставляются 
процессу. Если комбинации (ЫШ, СШ) нет в списке, в доступе к объекту отка¬ 
зывается. 

Использование групп вводит понятие роли. Рассмотрим систему, в которой 
Тана является системным администратором и поэтому входит в группу зузайт. 
Однако предположим, что в компании есть также клубы для сотрудников и Тана 
является членом клуба любителей голубей. Члены клуба принадлежат к группе 
рі&/ап и обладают доступом к компьютерам компании для управления своей голу¬ 
биной базой данных. Часть АСЬ-списка может быть показана в табл. 9.4. 


Таблица 9.4. Два элемента АСЬ-списка 


Файл 

Список управления доступом 

Раззѵѵогсі 

Іапа, зузайт: РѴѴ 

Рідеоп_сІаІа 

ЫН, рідіап: РѴѴ; Іапа, рідіап: РѴѴ;... 


Если Тана пытается получить доступ к одному из этих файлов, результат зави¬ 
сит от того, под какой учетной записью она зарегистрировалась в системе. Во вре¬ 
мя регистрации система может попросить ее выбрать группу, которую она на¬ 
меревается использовать. Также Тана может зарегистрироваться в системе под 
различными именами. Цель этой схемы состоит в том, чтобы Тана не могла иметь 
доступа к файлу паролей, когда занимается голубями. Доступ к файлу паролей она 
может получить только в том случае, когда регистрируется в системе как систем¬ 
ный администратор. 

В некоторых случаях пользователю может предоставляться доступ к опреде¬ 
ленным файлам независимо от того, к которой группе он принадлежит в данный 
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момент. Эта ситуация в записи АСЬ-списка может обозначаться, например, сим¬ 
волом звездочки, означающей все группы. Так, запись 

Іапа,* :КМ 

для файла паролей предоставила бы Тане доступ к нему независимо от того, к ко¬ 
торой группе Тана принадлежит в данный момент. 

Кроме того, права доступа могут предоставляться пользователю, принадлежа¬ 
щему к определенной группе, если эти права предоставлены всей группе. В дан¬ 
ном случае пользователь, принадлежащий одновременно к нескольким группам, 
не должен задумываться, какую группу указывать во время регистрации. При та¬ 
кой схеме членство в группах является постоянным и не указывается при регист¬ 
рации в системе. Недостаток такого подхода заключается в том, что он предостав¬ 
ляет меньшую степень инкапсуляции: Тана может редактировать файл паролей во 
время собрания голубиного клуба. 

С помощью групп и символов звездочки можно селективно блокировать оп¬ 
ределенного пользователя, отказав ему в доступе к конкретному файлу. Напри¬ 
мер, запись 

Ьаскег.* : (попе): *.* :КМ 

предоставляет разрешения чтения и записи файла всем пользователям, кроме 
пользователя Ьаскег. Это работает, так как записи сканируются слева направо и вы¬ 
бирается первая подходящая; последующие записи даже не изучаются. Следова¬ 
тельно, находится запись Ьаскег и соответствующий ей уровень доступа (попе), то 
есть никакого. На этом поиск прекращается. 

Другая схема работы с группами заключается в том, что записи АСЬ-списка 
состоят не из пар (ІІШ, СШ), а просто содержат только ЫШ или СШ. Например, 
запись для файла рщеоп_<іаІа может выглядеть следующим образом: 

йеЬЬіе: КМ: рНіІ: КМ: рідГап: КМ 

означая, что Дебби и Фил, а также все члены группы рі^ап могут читать и писать 
этот файл. 

Иногда бывает так, что у какого-либо пользователя или группы есть определен¬ 
ные разрешения доступа к файлу, которые владелец файла хотел бы у них отнять. 
С помощью списков управления доступом аннулировать предоставленные ранее 
права доступа довольно просто. Все, что для этого нужно, — это отредактировать 
АСЬ-список, чтобы внести соответствующие изменения. Однако если АСЬ-список 
проверяется только при открытии файла, вероятнее всего, эти изменения затронут 
только последующие системные вызовы ореп. Любой уже открытый файл будет 
сохранять права на этот файл, полученные при его открытии, даже если пользова¬ 
телю вообще запретили любой доступ к этому файлу, но уже после того, как он 
открыл файл. 

Перечни возможностей 

Матрица, показанная на рис. 9.16, может также храниться по рядам. При исполь¬ 
зовании этого метода с каждым процессом ассоциирован список объектов, к кото¬ 
рым может быть получен доступ, вместе с информацией о том, какие операции 
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разрешены с каждым объектом, другими словами, доменом защиты объекта. Такой 
список называется перечнем возможностей, а его элементы называются возмож¬ 
ностями [93, 113]. Пример трех процессов и их перечней возможностей показан 
на рис. 9.18. 



I Пространство 
Г пользователя 


у Пространство 
Г ядра 


Рис. 9.18. Использование АСЬ-списков для управления доступом к файлам 

Каждый элемент перечня возможностей предоставляет владельцу определен¬ 
ные права по отношению к определенному объекту. Например, на рис. 9.18 про¬ 
цесс, которым владеет пользователь А, может читать файлы Рі и Р2. Обычно эле¬ 
мент перечня возможностей состоит из идентификатора файла (или, в более общем 
случае, объекта) и битового массива для различных разрешений. В операционных 
системах типа ІЖІХ в качестве идентификатора файла может использоваться но¬ 
мер его і-узла. Перечни возможностей сами являются объектами и на них могут 
указывать другие перечни возможностей, таким образом облегчая совместное ис¬ 
пользование субдоменов. 

Очевидно, что перечни возможностей должны быть защищены от искажения 
их пользователями. Известны три способа их защиты. Для первого способа тре¬ 
буется теговая архитектура, то есть аппаратно реализованная структура памяти, 
в которой у каждого слова памяти есть дополнительный (теговый) бит, сообщаю¬ 
щий, содержит ли данное слово памяти элемент перечня возможностей или нет. 
Теговый бит не используется в обычных командах процессора, таких как арифме¬ 
тические или команды сравнения. Изменен он может быть только программой, 
работающей в режиме ядра (то есть операционной системой). Машины с подоб¬ 
ной архитектурой были построены и хорошо себя показали [116]. В качестве по¬ 
пулярного примера такой машины можно называть компьютер ІВМ А5/400. 

Второй способ состоит в том, что перечень возможностей хранится внутри опе¬ 
рационной системы. При этом к элементам перечня возможностей можно обра¬ 
щаться по их позиции в перечне. Процесс может запросить, например, прочитать 
1 Кбайт из файла, на который указывает элемент перечня возможностей номер 2. 
Такая форма адресации напоминает использование дескрипторов файла в ІЖІХ. 
Именно таким образом работала система Нусіга [365]. 
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Третий способ заключается в хранении перечня возможностей в пространстве 
пользователя, но в зашифрованном виде, так чтобы пользователь не смог изменить 
эту информацию. Этот метод хорошо подходит для распределенных систем и ра¬ 
ботает следующим образом. Когда клиентский процесс отправляет сообщение уда¬ 
ленному серверу, например файловому серверу, чтобы создать объект для него, 
сервер создает объект, а также формирует большое случайное число, используе¬ 
мое как контрольное поле. В таблице файлового сервера для объекта резервирует¬ 
ся запись, в которой также хранится контрольное поле, адреса дисковых блоков 
и т. д. В терминах системы ІЖІХ контрольное поле хранится на сервере в і-узле. 
Оно не посылается пользователю и вообще никогда не попадает в сеть. Затем сер¬ 
вер формирует и передает пользователю элемент перечня возможностей, формат 
которого показан на рис. 9.19. 


Сервер 

Объект 

Права 

1(ОЬІесІз,КідНІз,СНеск) 


Рис. 9.19. Элемент перечня возможностей, защищенный с помощью шифрования 


Возвращаемый пользователю элемент перечня возможностей содержит иден¬ 
тификатор сервера, номер объекта (индекс в таблицах сервера, по сути, і-узел), 
а также права доступа, хранящиеся в виде битового массива. У только что создан¬ 
ного объекта все биты разрешений установлены в единицу. Последнее поле пред¬ 
ставляет собой результат необратимой функции / от конкатенации объекта, прав 
и контрольного поля. Такая функция уже обсуждалась ранее. 

Когда пользователь желает получить доступ к объекту, он отправляет в запро¬ 
се серверу элемент перечня возможностей. Сервер извлекает из него номер объек¬ 
та и использует его в качестве индекса для поиска объекта в своих таблицах. За¬ 
тем он вычисляет /(О^есіз, Кщкіз, Скеск), причем первые два параметра для этой 
функции он берет из присланного ему пользователем элемента перечня возмож¬ 
ностей, а третий параметр из своих таблиц. Если результат совпадает с четвертым 
полем элемента перечня возможностей, запрос удовлетворяется, в противном слу¬ 
чае он отвергается. Если пользователь пытается получить доступ к чужому объек¬ 
ту, он не сможет подделать четвертое поле, так как не знает значения контрольно¬ 
го поля. 

Пользователь может попросить сервер создать элемент перечня возможностей 
с меньшими правами, например позволяющий только читать объект. Сначала сер¬ 
вер проверяет действительность элемента перечня возможностей. Если подпись 
совпадает, он вычисляет /(ОЬ]есСз, Мет_гіфіз, Скеск) для нового разрешения и со¬ 
здает новый элемент перечня возможностей, помещая это значение в четвертое поле. 
Обратите внимание, что при этом используется оригинальное значение контрольно¬ 
го поля Скеск, так как от него зависят другие элементы перечня возможностей. 

Этот новый элемент перечня возможностей посылается обратно запрашиваю¬ 
щему процессу. Теперь пользователь может передать его, скажем, отправив по 
электронной почте своему другу. Если друг попытается установить в единицу ка¬ 
кой-либо бит разрешения, сервер тут же обнаружит это, так как значение функ¬ 
ции /изменится. Поскольку другу неизвестно значение контрольного поля, он не 
сможет подделать элемент перечня возможностей так, чтобы тот соответствовал 
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фальшивым битам разрешений. Эта схема была разработана для распределенной 
операционной системы АтоеЬа и активно в ней применялась [324]. 

Помимо специфических разрешений, зависящих от конкретного объекта, на¬ 
пример чтение и исполнение, элементы перечня возможностей (как системные, так 
и защищенные шифрованием) содержат, как правило, общие права, то есть разре¬ 
шения выполнения действий, применимых ко всем объектам. Примерами таких 
действий являются: 

1. Копирование элемента перечня возможностей: создание нового элемента 
перечня возможностей для того же объекта. 

2. Копирование объекта: создание дубликата объекта с новым элементом пе¬ 
речня возможностей. 

3. Удаление элемента перечня возможностей: удаление записи в перечне воз¬ 
можностей; объект при этом не затрагивается. 

4. Удаление объекта: удаление объекта и элемента перечня возможностей. 

Напоследок стоит отметить, что аннулирование доступа к объекту в системах 

перечней возможностей, реализованных на уровне ядра, довольно сложно. Систе¬ 
ме трудно найти все элементы перечня возможностей для конкретного объекта, 
чтобы забрать их, так как они могут храниться в перечнях возможностей по всему 
диску. Один из методов заключается в том, что элемент перечня возможностей 
должен указывать не на сам объект, а на косвенный объект. Система может в лю¬ 
бой момент разорвать связь между объектом и указывающим на него косвенным 
объектом, таким образом, аннулируя все возможности. (Когда элемент перечня 
возможностей позднее появляется в системе, пользователь обнаружит, что косвен¬ 
ный объект теперь указывает на нулевой объект.) 

В системе АтоеЬа аннулирование разрешений выполняется легко. Все, что для 
этого требуется, — это изменить контрольное поле, хранимое с объектом. В резуль¬ 
тате одного удара все существующие элементы перечня возможностей становятся 
недействительными. Однако ни одна схема не обеспечивает выборочного аннули¬ 
рования разрешений, то есть невозможно, например, аннулировать разрешения 
Джона, не затронув всех остальных. Этот недостаток присущ всем системам пе¬ 
речней возможностей. 

Другая проблема состоит в том, чтобы гарантировать, что владелец действи¬ 
тельного элемента перечня возможностей не раздаст его копию 1000 своих луч¬ 
ших друзей. Эта проблема решается в системах типа Нусіга, в которых перечнями 
возможностей управляет ядро, но подобное решение не работает в распределен¬ 
ных системах, таких как АтоеЬа. 

С другой стороны, перечни возможностей позволяют очень элегантно решить 
проблему помещения мобильной программы в песочницу. При запуске чужая про¬ 
грамма получает список возможностей, содержащий только те возможности, кото¬ 
рые владелец машины согласен ей предоставить, например возможность вывода 
на экран и чтения и записи файлов из одного временного каталога, специально 
созданного для этой программы. Если мобильная программа помещается в соб¬ 
ственный процесс только с этими ограниченными возможностями, она не сможет 
получить доступ к другим системным ресурсам. Таким образом, программа ока¬ 
зывается в песочнице, для чего не требуется модификация кода или интерпрета- 
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ция программы. Запуск программы с минимальным набором прав доступа, назы¬ 
ваемый принципом наименьшего уровня привилегий, представляет собой мощное 
средство при создании защищенных систем. 

Итак, кратко подведем итоги. АСБ-списки и перечни возможностей обладают 
взаимодополняющими свойствами. Перечни возможностей очень эффективны, 
так как если процесс выдает запрос вида «Откройте файл, на который указывает 
элемент перечня возможностей 3», то не требуется никакой дополнительной про¬ 
верки. При использовании АСБ-списков для открытия файлов может потребовать¬ 
ся процесс поиска (возможно, долгий). Если группы не поддерживаются системой, 
тогда, чтобы предоставить доступ чтения файла всем пользователям системы, по¬ 
требуется перечислить всех пользователей в АСЕ-списке. Кроме того, перечни 
возможностей позволяют легко инкапсулировать процесс, чего не моіут АСЕ-спис- 
ки. С другой стороны, АСЕ-списки обеспечивают выборочное аннулирование разре¬ 
шений, тогда как при использовании перечней возможностей это нереально. Нако¬ 
нец, если объект удаляется, а элемент перечня возможностей нет или наоборот, 
возникают проблемы, которых лишены АСБ-списки. 


Надежные системы 

Большая часть этой главы была посвящена тому факту, что практически все со¬ 
временные компьютерные системы удерживают информацию так же надежно, как 
решето воду. Ежегодный ущерб, причиняемый вирусами и тому подобными про¬ 
блемами, превышает один миллиард долларов, затрачиваемых на попытки восста¬ 
новить поврежденные данные, не говоря уже об упущенной выгоде. Соответствен¬ 
но, возникают два очевидных вопроса: 

1. Возможно ли создание защищенной компьютерной системы? 

2. И если да, то почему она еще не создана? 

Ответ на первый вопрос в целом будет положительным. Как построить защищен¬ 
ную систему, известно уже в течение нескольких десятилетий. Например, у систе¬ 
мы МІІБТІС5, разработанной в 1960 году, безопасность была одной из главных 
целей, и эта цель была достигнута. 

Почему не создаются защищенные системы — вопрос более сложный. Здесь 
можно указать две фундаментальные причины. Во-первых, сегодняшние системы 
не являются защищенными, но пользователи не желают от них отказываться. Если 
бы корпорация Місгокоіі, например, объявила, что кроме системы \Ѵіпс1о\ѵ5 у нее 
есть новый продукт, некая защищенная высоконадежная операционная система 
5есиге05 с врожденным иммунитетом ко всем вирусам, но без поддержки \Ѵіпс1о\ѵз- 
приложений, то совсем не очевидно, что все индивидуальные пользователи и ком¬ 
пании тут же отказались бы от \Ѵіпс1о\ѵ5 и купили бы новую систему. 

Вторая причина не столь проста. Единственный способ создать защищенную 
систему состоит в том, чтобы сохранить систему простой. Изобилие функций яв¬ 
ляется злейшим врагом безопасности. Разработчики систем полагают (правы они 
или ошибаются — другой вопрос), что пользователи хотят видеть в системе все 
больше и больше разнообразных функций. Большее количество функций означа- 
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ет более высокий уровень сложности, соответственно, больше строк исходного тек¬ 
ста, больше ошибок и больше дыр в системе безопасности. 

Приведем два простых примера. В первых системах электронной почты сооб¬ 
щения посылались в виде А5СІІ-текста. Они были совершенно безопасны. Ничто 
в получаемом сообщении формата А5СІІ не могло повредить компьютерную сис¬ 
тему. Затем кому-то в голову пришла идея передавать электронной почтой и дру¬ 
гие типы документов, например файлы редактора ХѴогсІ, которые могут содержать 
макросы. Открытие такого документа означает запуск чужой программы на вашем 
компьютере. Независимо от того, какие песочницы применяются, запуск чужой 
программы на вашем компьютере опаснее, чем просмотр АЗСП-текста. Требовали 
ли пользователи возможности переключения электронной почты с пассивных до¬ 
кументов на активные программы? Возможно, нет, но разработчики систем поду¬ 
мали, что это будет замечательной идеей, не заботясь о связанных с этим пробле¬ 
мах безопасности. 

Второй пример представляет собой такой же переход с пассивных на активные 
элементы в \ѵеЬ-страницах. Когда Паутина состояла из пассивных НТМЬ-страниц, 
она не представляла собой основной проблемы безопасности (хотя намеренно не¬ 
корректная НТМЬ-страница могла вызвать переполнение буфера). Теперь, когда 
многие \ѵеЬ-страницы содержат программы (апплеты), запускаемые пользователем, 
чтобы просмотреть содержание \ѵеЬ-страницы, все новые дыры в системе безопас¬ 
ности обнаруживаются чуть ли не каждый день. Как только одну дыру удается зала¬ 
тать, ее место занимает другая. Когда Паутина была полностью статичной, требова¬ 
ли ли пользователи динамического содержания? Автор этого не припомнит, но 
ввод динамических элементов в Паутину привел к появлению массы проблем без¬ 
опасности. Похоже, что люди, ответственные за критическое отношение к нововве¬ 
дениям и обязанные в таких случаях говорить «Нет», просто уснули за штурвалом. 

Как ни странно, еще остались некоторые организации, считающие, что хорошая 
система безопасности важнее, чем различные модные навороты. К таким организа¬ 
циям относятся, например, военные. В следующих разделах мы рассмотрим не¬ 
сколько вопросов, касающихся защищенных систем, суть которых можно выразить 
в одной фразе. Для построения защищенной системы следует использовать в ядре 
операционной системы модель безопасности, достаточно простую, чтобы разработ¬ 
чики были способны ее понять, а также следует сопротивляться давлению отойти 
от используемой модели под предлогом добавления в систему новых функций. 


Высоконадежная вычислительная база 

Люди, занимающиеся компьютерной безопасностью, чаще употребляют термин 
надежная система (СгизСесі зузГет), чем «защищенная система» (зесиге зузГет). 
Надежная система — это система, в которой формально установлены требования 
безопасности и которая удовлетворяет этим требованиям. В сердце каждой надеж¬ 
ной системы находится минимальная база ТСВ (Тпізіесі СошриНп§ Вазе — высо¬ 
конадежная вычислительная база), состоящая из аппаратного программного обес¬ 
печения, необходимого для проведения в жизнь всех правил безопасности. Если 
высоконадежная вычислительная база работает в соответствии с техническими 
условиями, безопасность системы не может быть нарушена независимо от любых 
других обстоятельств. 
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Высоконадежная вычислительная база ТСВ, как правило, состоит из большей 
части аппаратного обеспечения (кроме устройств ввода-вывода, не влияющих 
на безопасность), части ядра операционной системы и большей части или всех 
пользовательских программ, обладающих полномочиями суперпользователя (на¬ 
пример, программы с установленным битом 5ЕТІІШ, владельцем которых явля¬ 
ется гооі в системе ІЖІХ). К функциям операционной системы, которые должны 
быть частью ТСВ, относятся создание процесса, переключение процессов, управ¬ 
ление картой памяти, а также часть файлового управления и управления вводом- 
выводом. В надежных системах база ТСВ часто представляет собой совершенно 
отдельную ото всей остальной операционной системы часть, что позволяет умень¬ 
шить ее размеры и проверить корректность работы. 

Важную часть высоконадежной вычислительной базы составляет монитор обра¬ 
щений, как показано на рис. 9.20. Монитор обращений принимает все системные 
вызовы, имеющие отношение к безопасности, такие как открытие файлов, и при¬ 
нимает решение, следует их выполнять или нет. Таким образом, монитор обраще¬ 
ний позволяет все решения о безопасности поместить в одном месте, не предо¬ 
ставляя возможности обойти их. Организация большинства операционных систем 
отличается от данной схемы, в чем заключается одна из причин их ненадежности. 



I Пространство 
[ пользователя 


1 Пространство 
Г ядра 


Рис. 9.20. Монитор обращений 


Формальные модели защищенных систем 

Матрицы защиты (см. рис. 9.15) нестатичны. Они часто меняются с созданием но¬ 
вых объектов, удалением старых объектов, а также когда владельцы объектов реша¬ 
ют расширить или ограничить набор разрешений или круг пользователей, которым 
предоставляется доступ к объекту. Значительное внимание было уделено модели¬ 
рованию систем защиты, в которых матрицы защиты постоянно меняются. В ос¬ 
тавшейся части данного раздела мы кратко рассмотрим некоторые из этих иссле¬ 
довательских работ. 

Несколько десятилетий назад Харрисон и его коллеги [145] определили шесть 
примитивных операций над матрицей защиты, которые могут использоваться как 
основа для моделирования любой системы защиты. Эти примитивные операции 
представляют собой создать объект, удалить объект, создать домен, удалить домен, доба- 
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вить разрешение и удалить разрешение. Два последних примитива добавляют и уда¬ 
ляют разрешения в определенном элементе матрицы, например предоставляют 
разрешение читать файл Рііеб домену 1. 

Эти шесть примитивов можно объединять в команды защиты, которые могут 
выполняться программами пользователя для изменения матрицы. Пользователь¬ 
ские программы не могут напрямую выполнять примитивы. Например, в системе 
может быть команда для создания нового файла, которая проверяет, существует 
ли уже этот файл, и если нет, создает новый объект и предоставляет владельцу все 
права к нему. Также может быть команда, позволяющая владельцу файла передать 
права чтения этого файла любому другому пользователю, для чего в каждый до¬ 
мен вставляется запись, дающая право чтения этого файла. 

В каждый момент времени матрица определяет, что может делать процесс в каж¬ 
дом домене, а не то, что ему разрешено делать. Матрица навязывается системой, 
разрешения относятся к политике управления. Чтобы это различие стало отчетли¬ 
вее, рассмотрим простой пример, в котором домены соответствуют пользователям 
(рис. 9.21). На рис. 9.21, а показана намеченная политика защиты: Генри может 
читать и писать данные в почтовом ящике таіІЬох7, Роберт может читать и писать 
файл зесгеі, и все три пользователя могут читать и исполнять файл сотрііег. 

Объекты Объекты 



Сотрііег 

МаіІЬох 7 

Зесгеі 


Сотрііег 
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Рис. 9.21 . Дозволенное состояние (а); недозволенное состояние (б) 


Теперь представим себе, что Роберт очень умен и нашел способ подавать коман¬ 
ды, изменяющие матрицу из состояния на рис. 9.21, а в состояние на рис. 9.21, б. 
При этом он получает доступ к файлу таіІЪох7. Если он попытается его прочитать, 
операционная система выполнит его запрос, ведь ей не известно, что состояние на 
рис. 9.21, б не является дозволенным. 

Теперь должно быть ясно, что множество всех возможных матриц может быть 
разделено на два раздельных подмножества: множество всех дозволенных состоя¬ 
ний и множество всех недозволенных состояний. Вопрос, которому было посвя¬ 
щено множество исследований, звучит следующим образом: «При заданном на¬ 
чальном дозволенном состоянии и наборе команд можно ли гарантировать, что 
система никогда не перейдет в недозволенное состояние?» 

Таким образом, требуется ответить на вопрос о том, способен ли имеющийся 
механизм (набор команд защиты) провести в жизнь определенную политику за¬ 
щиты. Итак, у нас есть политика, начальное состояние матрицы и набор команд 
для модифицирования матрицы; при этом нам требуется способ гарантировать 
защищенность системы. Оказывается, такую защиту довольно трудно обеспечить. 
Многие операционные системы не являются защищенными даже в теории. Харри- 
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сон и его коллеги доказали, что в случае произвольной конфигурации для произ¬ 
вольной системы защиты защита является теоретически недостижимой [145]. 
Однако для конкретной системы можно доказать, что система может быть переве¬ 
дена из дозволенного состояния в недозволенное. Дополнительные сведения мож¬ 
но получить в [196]. 

Многоуровневая защита 

Большинство операционных систем позволяют индивидуальным пользователям 
определять, кто может читать и писать их файлы, а также иметь доступ к другим 
их объектам. Такая политика называется дискреционным управлением досту¬ 
пом. Во многих окружениях эта модель прекрасно работает, но существуют среды, 
в которых необходимы значительно более жесткие требования к безопасности, как, 
например, в воинских частях, патентных отделах корпораций и больницах. В этих 
системах организации устанавливают правила, определяющие, кто и что может 
видеть, и эти правила не могут изменять солдаты, юристы или врачи, по крайней 
мере, без специального разрешения от своего начальства. Для таких систем, помимо 
стандартного дискреционного управления доступом, требуется принудительное 
управление доступом, чтобы гарантировать, что установленная политика безопас¬ 
ности реализуется системой. Принудительное управление доступом регулирует 
поток информации, гарантируя, что эта информация не потечет по маршруту, по 
которому ей течь не полагается. 

Модель Белла-Ла Па дулы 

Из многоуровневых систем защиты самое широкое распространение получила 
модель Белла-Ла Падулы, поэтому мы начнем наше обсуждение многоуровневых 
систем защиты с нее [24]. Эта модель была разработана для обеспечения военной 
системы безопасности, но она также применима и в мирных целях. В военных орга¬ 
низациях все документы (объекты) могут иметь уровни секретности, такие как не¬ 
секретный, конфиденциальный, секретный и совершенно секретный. Военнослу¬ 
жащим также присваиваются различные уровни доступа к данной информации. 
Генералу может быть разрешено просматривать все документы, тогда как лейтенант 
может иметь доступ только к двум нижним уровням. Процесс, работающий в систе¬ 
ме, приобретает уровень доступа запустившего его пользователя. Так как уровней 
секретности много, эта схема называется многоуровневой системой безопасности. 

В модели Белла-Ла Падулы поток информации описывается следующими пра¬ 
вилами: 

1. Простое свойство секретности. Процесс, работающий на любом уровне 
секретности, может читать только объекты своего уровня или более низ¬ 
ких уровней секретности. Например, генерал может читать документы лей¬ 
тенанта, но лейтенант не может читать документы генерала. 

2. Свойство *. Процесс, работающий на любом уровне секретности, может пи¬ 
сать только в объекты своего уровня или более высоких уровней секрет¬ 
ности. Например, лейтенант может добавить сообщение к почтовому ящи¬ 
ку генерала, сообщая все, что ему известно, но генерал не может сделать то 
же самое с почтовым ящиком лейтенанта, так как ему могут быть известны 
сверхсекретные документы, которые не полагается знать лейтенанту. 
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Итак, в первом приближении процессы могут читать снизу и писать наверх, но 
не наоборот. Если система гарантированно реализует эти два свойства, можно до¬ 
казать, что не будет утечки информации с уровня большей секретности на уровень 
меньшей секретности. Это свойство было названо *, потому что в своем ориги¬ 
нальном докладе авторы не смогли придумать для него подходящего названия 
и отложили задачу выдумывания имени на потом, решив временно использовать 
символ *. Они так и не придумали этого названия, и доклад был напечатан со звез¬ 
дочкой вместо него. В данной модели процессы читают и пишут объекты, но не 
общаются друг с другом напрямую. Графически модель Белла-Ла Падулы проил¬ 
люстрирована на рис. 9.22. 

Уровень секретности 



Рис. 9.22. Многоуровневая модель безопасности Белла-Ла Падулы 

На данном рисунке сплошными стрелками от объекта к процессу показано на¬ 
правление информации при ее чтении процессом из объекта. Аналогично, штри¬ 
ховая стрелка от процесса к объекту означает запись данных в объект. Таким об¬ 
разом, вся информация течет по направлению стрелок. Например, процесс В может 
читать данные из объекта 1, но не из объекта 3. 

Простое свойство секретности утверждает, что все сплошные стрелки (чтение) 
могут направляться в стороны или вверх. Свойство * говорит, что все штриховые 
стрелки (запись) могут также направляться в стороны или вверх. Поскольку инфор¬ 
мация распространяется только горизонтально или вверх, она не может попасть 
с более высокого уровня на более низкий. Другими словами, не может существовать 
пути информации сверху вниз, тем самым гарантируется защищенность модели. 

Модель Биба 

Итак, если перевести модель Белла-Ла Падулы на язык военных, лейтенант может 
приказать рядовому рассказать все, что ему известно, а затем скопировать эту ин¬ 
формацию в файл генерала, не нарушив секретности. Теперь переведем эту модель 
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в термины гражданских лиц. Представим себе компанию, в которой у уборщиц 
уровень секретности 1, у программистов — уровень 3, а у президента компании 
уровень секретности 5. Используя модель Белла-Ла Падулы, программист может 
выведать у уборщицы стратегические планы компании, а затем перезаписать файл 
президента, содержащий стратегию корпорации. Не всем компаниям понравилась 
бы перспектива использования такой модели. 

Недостаток модели Белла-Ла Падулы состоит в том, что она была разработана 
для хранения секретов, а не для гарантирования целостности данных. Чтобы 
гарантировать целостность данных, нам потребуются как раз противоположные 
свойства [32]: 

1. Простой принцип целостности. Процесс, работающий на любом уровне сек¬ 
ретности, может писать только в объекты своего уровня или более низких 
уровней секретности (запись в верхние уровни запрещена). 

2. Свойство целостности *. Процесс, работающий на любом уровне секретно¬ 
сти, может читать только в объекты своего уровня или более высоких уров¬ 
ней секретности (запрещено чтение низких уровней). 

Вместе эти свойства гарантируют, что программист может изменять файлы 
уборщицы, записывая туда информацию, полученную от президента фирмы, но не 
наоборот. Конечно, некоторые организации хотели бы использовать одновремен¬ 
но и свойства модели Белла-Ла Падулы, и свойства модели Биба, но поскольку 
они противоречат друг другу, достичь этого сложно. 

Оранжевая книга безопасности 

Министерство обороны США также приложило определенные усилия к области 
развития систем безопасности. В частности, в 1985 году оно опубликовало доку¬ 
мент, формально зарегистрированный как стандарт Министерства обороны США 
ЭоЭ 5200.28, но обычно называемый благодаря своей обложке Оранжевой книгой, 
в которой операционные системы подразделяются на семь категорий в зависимо¬ 
сти от их свойств безопасности. Хотя с тех пор этот стандарт был заменен другим 
(намного более сложным), Оранжевая книга все еще представляет собой хорошее 
руководство в области безопасности систем. Кроме того, периодически можно 
встретить заявления производителей программного обеспечения о соответствии 
тому или иному уровню безопасности Оранжевой книги. Требования Оранжевой 
книги приведены в табл. 9.5. Ниже мы рассмотрим категории безопасности и вы¬ 
делим некоторые важные места. Символ X означает, что появились новые требо¬ 
вания. Символ -э означает, что на данном уровне применимы требования более 
низкой категории. 

Уровни В и А требуют, чтобы всем управляемым пользователям и объектам 
были присвоены метки безопасности, такие как несекретный, секретный или сверх¬ 
секретный. Эта система должна поддерживать модель потоков информации Бел¬ 
ла-Ла Падулы. 

Уровень В2 добавляет к этому требование, заключающееся в том, что система 
должна разрабатываться сверху вниз в модульном виде. Конструкция системы 
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должна быть представлена в таком виде, чтобы ее можно было проверить. Должна 
быть проверена возможность наличия тайных каналов (см. следующий раздел). 

Таблица 9.5. Критерии безопасности Оранжевой книги 






Критерий О 

С1 

С2 

В1 

В2 

ВЗ 

А1 

Политика секретности 

Дискреционное управление доступом 

X 

X 

— » 

— ^ 

X 

— > 

Повторное использование объекта 


X 

— » 

— ^ 

— > 

— > 

Метки 



X 

X 

— > 

— > 

Целостность меток 



X 


— > 

—» 

Экспорт меченой информации 



X 



—» 

Маркировка вывода, удобочитаемого для человека 



X 




Принудительное управление доступом 



X 

X 


—» 

Метки, чувствительные к предмету 




X 

—> 

— > 

Метки устройств 




X 

—^ 

—^ 

Возможность идентификации 

Идентификация и аутентификация 

X 

X 

X 



—> 

Аудит 


X 

X 

X 

X 

—^ 

Надежный путь 




X 

X 

—^ 

Гарантирование 

Архитектура системы 

X 

X 

X 

X 

X 

—» 

Целостность системы 

X 

— » 

—» 

—^ 

—» 

— » 

Тестирование безопасности 

X 

X 

X 

X 

X 

X 

Спецификация и верификация дизайна 



X 

X 

X 

X 

Анализ тайных каналов 




X 

X 

X 

Надежное управление средствами 




X 

X 

— » 

Управление конфигурацией 




X 

—» 

X 

Надежное восстановление 





X 

—^ 

Надежное распространение 






X 

Документация 

Руководство пользователя по безопасности 

X 

—^ 

—> 

—» 

—> 

—> 

Руководство по надежным средствам 

X 

X 

X 

X 

X 

—> 

Тестовая документация 

X 

—^ 

—> 

X 

—^ 

X 

Документация разработчика 

X 

—> 

X 

X 

X 

X 


Уровень ВЗ содержит все свойства уровня В2, плюс он должен содержать АСЬ- 
списки с пользователями и группами; на нем также должны присутствовать фор¬ 
мальная высоконадежная вычислительная база ТСВ, адекватный аудит безопас¬ 
ности и надежное восстановление от сбоев. 

Уровень А1 требует наличия формальной модели системы защиты и гарантии кор¬ 
ректности этой модели. Он также требует доказательств, что реализация системы 
соответствует модели. Тайные каналы должны быть формально проанализированы. 
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Тайные каналы 

Все эти идеи о формальных моделях и гарантированно безопасных системах зву¬ 
чат замечательно, но работают ли они в действительности? Если ответить на этот 
вопрос одним словом, то нет. Даже в корректно реализованной системе, в основе 
которой лежит правильная модель безопасности и безопасность которой была до¬ 
казана, могут случаться проколы в системе безопасности. В данном разделе мы 
обсудим, как информация может утекать даже в системах, для которых было стро¬ 
го математически доказано, что подобные утечки невозможны. Идеи, изложенные 
в данном разделе, были высказаны Лэмпсоном в [193]. 

Модель Лэмпсона изначально была сформулирована в терминах единой сис¬ 
темы разделения времени, но те же идеи могут быть применены к локальной сети, 
а также другим многопользовательским средам. В ее чистом виде в эту модель вхо¬ 
дят три процесса, работающих на одной защищенной машине. Первый процесс 
представляет собой клиент, который хочет выполнить некоторое задание на вто¬ 
ром процессе, сервере. Клиент и сервер доверяют друг другу не полностью. На¬ 
пример, работа сервера заключается в том, чтобы помочь клиентам заполнить их 
налоговые декларации. Клиенты беспокоятся, что сервер тайно запишет их финан¬ 
совую информацию, а затем, например, продаст эти сведения. Сервер беспокоит¬ 
ся, что клиенты украдут ценную программу подсчета налогов. 

Третий процесс, называемый в данной модели «сообщником» (буквально 
соІІаЬогаІог, то есть «сотрудник»), намеревается украсть конфиденциальные све¬ 
дения клиента. Владельцем этого процесса и сервера, как правило, является один 
и тот же человек. Все три процесса показаны на рис. 9.23. Цель данной модели со¬ 
стоит в том, чтобы разработать систему, в которой невозможна утечка информа¬ 
ции, полученной сервером у клиента, к «сотрудничающему» процессу. Лэмпсон 
назвал это проблемой ограждения. 


Клиент Сервер Сообщник 



а 


Инкапсулированный сервер 



Тайный 

канал 


Рис. 9.23. Клиент, сервер и «сообщник» (а); от инкапсулированного сервера 
информация все равно может утекать «сообщнику» по тайному каналу (б) 


С точки зрения разработчика системы задача заключается в инкапсуляции или 
ограждении сервера таким образом, чтобы он не мог передать информацию «со¬ 
общнику». С помощью схемы матрицы защиты несложно гарантировать, что 
сервер не сможет общаться с «сообщником», записывая данные в файл, к которо¬ 
му у «сообщника» есть доступ для чтения. Вероятно, можно также гарантировать, 
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что сервер не сможет общаться с «сообщником» при помощи системного механиз¬ 
ма межпроцессного взаимодействия. 

К сожалению, для утечки информации могут использоваться тайные каналы. 
Например, сервер может передавать последовательность нулей и единиц, кодируя 
единицы интервалами высокой активности процессора, а нули обозначая интер¬ 
валами бездействия. «Сообщник» может попытаться принять этот поток, тщатель¬ 
но отслеживая время отклика сервера. Как правило, время отклика будет меньшим 
у простаивающего сервера, что соответствует нулю. Этот канал связи называется 
тайным каналом. Он показан на рис. 9.23, 6. 

Конечно, тайный канал представляет собой канал с шумом, но если исполь¬ 
зовать помехоустойчивое кодирование (например, код Хэмминга), информация 
может приниматься «сообщником» с высокой степенью надежности. Пропускная 
способность такого канала будет невелика, но это не снижает его опасности. Оче¬ 
видно, что ни одна из моделей защиты, основанных на матрицах объектов и доме¬ 
нов, не сможет предотвратить данный тип утечки информации. 

Модуляция использования центрального процессора не является единственным 
вариантом тайного канала. Информация также может кодироваться страничными 
прерываниями, например, много прерываний в течение определенного интервала 
времени будет означать 1, а отсутствие страничных прерываний — 0. В принципе 
для этой цели может использоваться любой способ снижения производительнос¬ 
ти системы в течение определенного интервала времени. Если система позволяет 
блокировать файлы, тогда сервер может блокировать некий файл, что будет озна¬ 
чать, например, 1, и разблокировать его, кодируя, таким образом, 0. Некоторые 
системы позволяют процессу определить, что файл блокирован, даже если у него 
нет доступа к этому файлу. Такой тайный канал показан на рис. 9.24. В данном 
примере сервер передает сообщнику тайный поток бит 11010100. 


Сервер — Г) О О О О О О О 


Сервер 
блокирует 
файл, чтобы 
послать 1 


Сообщник. 



оооооооо 


Сервер разблокирует 
файл, чтобы послать 0 


-ч — Посланный 
битовой поток 


Время 


Рис. 9.24. Использование блокировки файла для тайного канала 


Блокировка и разблокировка файла, о которых сервер и сообщник договори¬ 
лись заранее, не является особенно шумным каналом, однако для такого типа свя¬ 
зи требуется особенно точная синхронизация, если только скорость передачи не 
очень низкая. Если использовать протокол с подтверждениями, то надежность и 
производительность такого тайного канала может быть значительно увеличена. 
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Для синхронизации сервер и сообщник открывают сразу три файла, 5, Р\ и Р2, два 
из них блокируются сервером, а третий — сообщником. После того как сервер 
блокирует или разблокирует файл 5, он изменяет состояние блокировки файла Рі, 
сообщая тем самым сообщнику, что бит отправлен. Прочитав бит, сообщник 
изменяет в ответ состояние блокировки файла Р2, подтверждая, что бит прочитан. 
Поскольку в данной схеме параметры времени не участвуют, этот протокол ока¬ 
зывается абсолютно надежным даже в системе, в которой одновременно запущено 
много процессов и сервер и центральный процессор сильно заняты. Скорость 
такого тайного канала данных зависит от того, насколько часто система пере¬ 
ключает процессы. Повысить пропускную способность такого канала можно, если 
использовать одновременно два файла, 50 и 51, передавая сразу по два бита одно¬ 
временно, или даже восемь файлов, передавая сразу один байт. 

Для передачи скрытых сигналов также может использоваться захват и освобож¬ 
дение внешних ресурсов (например, магнитофонов, плоттеров ит. д.). В системе 
ІЖІХ сервер может создавать файл, что будет означать 1, и удалять его, переда¬ 
вая 0. Сообщник может проверять наличие файла при помощи системного вызова 
ассезз. Этот системный вызов будет работать, даже если у сообщника нет доступа 
к создаваемому сервером файлу. К сожалению, существует еще множество возмож¬ 
ностей создания скрытого канала. 

Лэмпсон также упомянул о еще одном возможном тайном канале связи, но уже 
между сервером и человеком. Например, сервер может сообщать, сколько работы 
он сделал для клиента, выставляя ему счет. Если настоящий счет составляет $100, 
а доход клиента составил $53 000, то сервер может сообщить об этом в виде счета 
в $100,53. 

Обнаружить все скрытые каналы чрезвычайно трудно, не говоря уже об их бло¬ 
кировке. На практике можно сделать не слишком многое. Добавление процесса, 
вызывающего страничные прерывания случайным образом или снижающего про¬ 
изводительность системы другим способом, чтобы снизить пропускную способ¬ 
ность скрытых каналов, в качестве варианта решения проблемы не привлекает. 

До сих пор мы предполагали, что клиент и сервер являются раздельными про¬ 
цессами. Другой вариант представляет собой только один работающий клиент¬ 
ский процесс, но при этом работающая клиентская программа является троянс¬ 
ким конем. Такая схема может, например, применяться в том случае, когда система 
не позволяет сообщнику получить данные от сервера напрямую. 

Существует еще одна интересная разновидность скрытого канала. Представьте 
себе компанию, которая вручную проверяет всю исходящую электронную почту, 
посылаемую сотрудниками, чтобы гарантировать, что никто не делится с конкурен¬ 
тами секретами фирмы. Есть ли способ, с помощью которого сотрудник компании 
может передать значительный объем конфиденциальной информации за пределы 
фирмы, прямо под носом цензора? Оказывается, есть. 

Пример такого метода показан на рис. 9.25, а. На этой фотографии, снятой ав¬ 
тором в Кении, мы видим трех зебр возле акации. Теперь взгляните на рис. 9.25, б. 
На первый взгляд, те же зебры и та же акация. Однако данная фотография, в отли¬ 
чие от первой, содержит также полный текст пяти пьес Шекспира, а именно: 




Надежные системы 


727 


«Гамлет», «Король Лир», «Макбет», «Венецианский купец» и «Юлий Цезарь». 
Все вместе они составляют более 700 Кбайт текста. 

Как работает этот тайный канал? Оригинальное изображение состоит из 1024х 
768 пикселов. Каждый пиксел состоит из трех 8-разрядных чисел, по одному для 
интенсивности красного, зеленого и синего цветов пиксела. Цвет пиксела представ¬ 
ляет собой линейную суперпозицию трех цветов. Для кодирования скрытого кана¬ 
ла используются младшие разряды каждого значения цвета в формате КОВ. Таким 
образом, в каждом пикселе помещается три бита секретной информации. В изоб¬ 
ражении данного размера может поместиться 1024x768x3 бит или 294 912 байт 
секретной информации. 



а б 

Рис. 9.25. Три зебры и дерево (а); три зебры, дерево и полный текст пяти пьес Шекспира (б) 


Полный текст пяти пьес и короткого сообщения составляют 734 891 байт. При 
помощи стандартного алгоритма сжатия этот размер может быть уменьшен до 
274 байт. Затем результат сжатия шифруется и помещается в младшие разряды 
каждого байта цвета. Как видно (то есть не видно), присутствие этой информации в 
изображении абсолютно незаметно на глаз. На большом цветном изображении этой 
информации также не видно. Человеческий глаз не в состоянии отличить 7-раз- 
рядный цвет от 8-разрядного. После того как эта фотография благополучно мину¬ 
ет цензора, получатель просто считывает из файла младшие разряды, применяет 
алгоритмы дешифрации и распаковки и получает исходные 734 891 байт текста. 
Данный способ сокрытия информации называется стеганографией (что по-гречес¬ 
ки означает «скрытая надпись»). Стеганографию не любят правительства, пытаю¬ 
щиеся ограничить общение между их гражданами, но этот метод весьма популя¬ 
рен среди людей, верящих в свободу слова. 

Конечно, два черно-белых изображения низкого разрешения не могут дать пол¬ 
ного представления о мощи данного метода. Чтобы предоставить читателю более 
убедительное доказательство, автор подготовил набор файлов, включая изображе¬ 
ние, показанное на рис. 9.25, б, которые можно скачать с \ѵеЬ-сайта ѵѵѵѵѵѵ.С5.ѵи.пІ/~а5І/. 
Щелкните мышью на ссылке соѵегесі ѵѵгіііпд под заголовком 5ТЕСАЦОСКАРНУ 
ЦЕМО. Затем выполните указанные на этой странице инструкции для загрузки 
изображения и программ, необходимых для извлечения пьес. 






728 


Глава 9. Безопасность 


Кроме того, стеганография может применяться для добавления к изображе¬ 
ниям скрытых «водяных знаков». Подобный метод позволяет обнаружить и дока¬ 
зать факт кражи изображений с \ѵеЬ-страницы и их повторного использования. 
Если окажется, что ваше изображение содержит скрытое сообщение, например, 
«Соругі§Ьі 2000, Сепегаі Іша§ез СогрогаПоп», то вам, скорее всего, будет очень 
трудно убедить судью, что это изображение вы изготовили сами. Данный метод 
также может использоваться для защиты музыки, фильмов и т. д. 

Конечно, подобные «водяные знаки» можно попытаться удалить. Например, 
водяные знаки на изображении полностью уничтожаются, если повернуть изоб¬ 
ражение по часовой стрелке на один градус, затем применить преобразование с поте¬ 
рей информации, скажемДРЕС, а затем повернуть изображение снова на один гра¬ 
дус, но влево. Наконец, изображение можно снова конвертировать в его исходный 
формат (например, СІЕ, ВМР или ТІЕ). Преобразование с потерей данных^ЕС 
перемешает все младшие разряды, а поворот изображения добавит ошибок округ¬ 
ления при операциях с плавающей точкой, что также добавит шума к младшим 
разрядам. Люди, пытающиеся защитить свои цифровые данные водяными знака¬ 
ми, знают это, и поэтому они пытаются применять схемы с избыточностью, а так¬ 
же применяют другие схемы, кроме использования младшего бита. В ответ на это 
взломщики также пытаются применять более изощренную технику и т. д. 


Исследования в области безопасности 

Компьютерная безопасность представляет собой тему, которой посвящено очень 
много исследований, однако большая их часть не связана напрямую с операцион¬ 
ной системой. Основные исследования в этой области затрагивают такие темы, как 
безопасность сетей (например, электронной почты, Паутины, а также безопасность 
электронной коммерции), криптографию, ^ѵа или просто надежное управление 
компьютерной системой. 

Однако также проводились исследования, более близкие к теме нашей книги. 
Например, все еще сохраняет актуальность проблема аутентификации пользовате¬ 
лей. Монроуз и Рубин [238] исследовали проблему распознавания пользователей 
по динамике нажатий на клавиши, Пентланд и Чаудхури [262] приводят аргумен¬ 
ты в пользу распознавания лиц пользователей, а Марк [223] среди прочих разра¬ 
ботал метод моделирования данной схемы. 

Вот еще несколько работ, относящихся к безопасности операционных систем. 
Бершад с соавторами [27] отстаивают свою точку зрения, заключающуюся в том, 
что защита является вопросом программного обеспечения, а не аппаратного обес¬ 
печения (то есть ММЕІ). Мазирес и его коллеги [228] рассматривают защищен¬ 
ные распределенные файловые системы. Майерс и Лисков [242] изучают модели 
надежных информационных потоков. Чейз с соавторами [60] исследуют безопас¬ 
ность в системах с большим адресным пространством, занятым большим количе¬ 
ством процессов. Безопасности смарт-карт посвящена работа Кларка и Хоффма¬ 
на [69]. Гольдберг и другие исследователи [129] занимались конструированием 
филогенезов вирусов. 
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Резюме 

Операционные системы могут подвергаться различным атакам, от атак изнутри до 
вирусных атак. Многие атаки начинаются с того, что взломщик пытается просто уга¬ 
дать пароль. Для таких атак часто используются словари наиболее употребляемых 
паролей. Подобные атаки часто бывают удивительно успешными. Безопасность па¬ 
ролей может быть усилена при помощи так называемой «соли», одноразовых паро¬ 
лей, а также схемы «оклик-отзыв». Также могут применяться смарт-карты и биомет¬ 
рические индикаторы. На практике часто используется сканирование сетчатки глаза. 

Существует много разновидностей атак операционной системы, включая тро¬ 
янского коня, фальшивые программы регистрации, логические бомбы, потайные 
входы и атаки, использующие переполнение буфера. Кроме того, могут использо¬ 
ваться такие методы, как запрашивание страниц памяти и считывание информации, 
оставшейся в них, обращение к запрещенным системным вызовам и даже попыт¬ 
ки обмана или подкупа сотрудников с целью выведать секретную информацию. 

Все большую проблему последнее время представляют собой вирусы. Существу¬ 
ет большое разнообразие форм вирусов, включая вирусы, резидентные в памяти, 
вирусы, заражающие загрузочный сектор диска, а также макровирусы. Использо¬ 
вание антивирусной программы, ищущей зараженные файлы по определенным 
последовательностям байт, полезно, но серьезные вирусы могут зашифровать 
большую часть своего кода, а также модифицировать остальную часть при репли- 
цировании, что очень сильно усложняет их обнаружение. Некоторое антивирус¬ 
ное программное обеспечение не ищет определенные куски вирусов, а пытается 
поймать их за подозрительными действиями. Лучшим средством против вирусов 
является предохранение от вирусов. Поэтому не загружайте и не запускайте про¬ 
грамм, авторство которых неизвестно и доверие к которым под вопросом. 

В последние годы все большую популярность приобретают мобильные програм¬ 
мы, например активные \ѵеЬ-страницы. К возможным средствам борьбы с потенци¬ 
альной опасностью таких программ относятся помещение мобильной программы 
в «песочницу», интерпретация программы, а также запуск только программ, под¬ 
писанных доверенными производителями. 

Операционные системы могут защищаться с помощью матриц, состоящих из 
доменов защиты (например, пользователей) по вертикали, объектов по горизон¬ 
тали. Матрица может храниться по рядам (перечни возможностей) или по столб¬ 
цам (АСЛ-списки). 

Защищенные системы можно разработать, но безопасность должна быть главной 
целью с самого начала работы над проектом операционной системы. Вероятно, наи¬ 
более важное правило разработки системы заключается в создании минимальной 
высоконадежной вычислительной базы ТСВ, которую нельзя обойти, пытаясь по¬ 
лучить доступ к любому ресурсу. Многоуровневая система безопасности может 
основываться на модели БеллаЛа-Падулы, разработанной для хранения секретов, 
или на модели Биба, созданной для поддержания целостности системы. В Оран¬ 
жевой книге описываются требования, которым должны удовлетворять надежные 
системы. Наконец, даже если система с большой вероятностью является надеж¬ 
ной, следует уделить внимание тайным каналам, которые легко могут низвергнуть 
систему, если ее модель не учитывает возможности их наличия. 
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Вопросы 

1. Рассмотрим шифр с секретным ключом, представляющий собой матрицу 
26 х 26, заголовки столбцов и строк которой содержат символы АВС.. .2. От¬ 
крытый текст шифруется по два символа. Первый символ указывает столбец, 
а второй — строку. В ячейке матрицы на пересечении столбца и строки содер¬ 
жатся два символа зашифрованного текста. Какие правила должны выпол¬ 
няться для этой матрицы? Сколько возможно ключей у такого шифра? 

2. Расшифруйте следующее сообщение, составленное с помощью моноалфа- 
витного шифра. Открытый текст, состоящий только из букв, представляет 
собой хорошо известный отрывок из поэмы Льюиса Кэрролла. 

кГй кГМ Гдп еиМ кГй ріуіот пкіх ки кіуд иг ЬгИа кГГНст 
иг тГийт 2Их шГІпіл 2Их тсЕуГНс р іц иг егззгссіт 2Их дГНст 
2Ііх рГа кГР тсЕ Гт зиГуЫіс Гик 2Ііх рГйкГсІі піст Г2ІЙ рГНст 
$ок ргік г $Гк кГй иатксііт еіісіх $Ргиіс 1 рсі ГЛсІ иоі еГік 
гиі тиЬсІ иг от 2іР иок иг зісЕкГ гкіх гуу иг от 2іР Г2к 
(іи Гоііа тгГх кГР егіпсІИксІі кГРа кГіРдсІх ГГЬ ЬоеГ гиі кГік 

3. Рассмотрите следующий способ шифрования файла. Для алгоритма шифро¬ 
вания используется два га-байтовых массива, А я В. Первые га байтов считы¬ 
ваются из файла в массив А. Затем Л[0] копируется в В[і], А[ 1] копируется 
вВ[у],Л[2] копируется вВ[к\ ит. д. После того как все га байтов скопированы 
в массив В, этот массив записывается в выходной файл, после чего в массив А 
считываются следующие га байтов. Эта процедура повторяется до тех пор, 
пока не будет зашифрован весь файл. Обратите внимание, что в данной схеме 
шифрования символы не заменяются одни другими, а меняются местами. 
Сколько ключей следует перебрать, чтобы путем полного перебора взломать 
данный шифр? Укажите преимущество данной схемы перед моноалфавит- 
ным подстановочным шифром. 

4. Шифрование с секретным ключом более эффективно, нежели шифрование 
с открытым ключом, но оно требует, чтобы отправитель и получатель зара¬ 
нее договорились об используемом ключе. Предположим, что отправитель 
и получатель никогда не встречались, но существует доверенная третья сто¬ 
рона, у которой есть общий секретный ключ с отправителем и другой об¬ 
щий секретный ключ с получателем. Как при таких обстоятельствах отпра¬ 
витель и получатель могут установить новый общий секретный ключ? 

5. Приведите простой пример математической функции, которая в первом 
приближении может использоваться как необратимая функция. 

6. Отсутствие эха при вводе пароля безопаснее, чем вывод эха в виде звез¬ 
дочек вместо каждого символа, так как последний вариант позволяет опре¬ 
делить длину пароля любому, кто окажется рядом с экраном. Если пред¬ 
положить, что пароль состоит только из букв в верхнем и нижнем регистре 
и цифр, а длина его — от 5 до 8 знаков, то насколько безопаснее вообще ни¬ 
чего не отображать? 

7. Закончив учебное заведение, вы получаете место директора большого универ¬ 
ситетского компьютерного центра, который только что выгнал свой древний 
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мэйнфрейм на пастбище и переключился на большой сервер локальной сети 
с операционной системой ІЖІХ. Вы начинаете работать. Через пятнадцать 
минут после начала работы ваша ассистентка вбегает в кабинет с криком: 
«Какие-то студенты обнаружили алгоритм, которым мы шифруем наши па¬ 
роли, и поместили его в Интернете». Какие будут ваши действия? 

8. Схема защиты Морриса—Томпсона с и-разрядными случайными числами 
(«солью») была разработана, чтобы затруднить взломщику отгадывание па¬ 
ролей при помощи зашифрованного заранее словаря. Защищает ли такая 
схема от студентов, пытающихся угадать пароль суперпользователя? Пред¬ 
полагается, что файл паролей доступен для чтения. 

9. Назовите три характеристики, которые должен иметь хороший биометри¬ 
ческий индикатор, чтобы его можно было использовать для аутентифика¬ 
ции при входе в систему. 

10. Существует ли какой-либо способ использовать аппаратуру ММИ для пре¬ 
дотвращения атаки переполнением, показанную на рис. 9.6? Объясните, по¬ 
чему да, или почему нет. 

11. У факультета технической кибернетики есть локальная сеть с большим коли¬ 
чеством машин, работающих под управлением операционной системы ІЖІХ. 
Пользователь на любой машине может ввести команду вида тасИІ пе4 мію, 
и эта команда будет выполнена на компьютере таскіпе4, для чего пользова¬ 
телю не нужно регистрироваться на удаленном компьютере. Это свойство 
реализовано следующим образом. Ядро системы машины пользователя по¬ 
сылает команду и ее ИШ удаленной машине. Надежна ли такая схема, если 
ядрам системы можно доверять? Что, если одна из машин представляет со¬ 
бой персональный компьютер студента, на который не установлена защита? 

12. Что общего у реализации паролей в операционной системе ІЖІХ со схемой 
Лампорта для регистрации по незащищенной сети? 

13. Схема одноразовых паролей Лампорта использует пароли в обратном по¬ 
рядке. Не проще ли было бы в первый раз использовать /(х), во второй — 
/(/О» ит.д.? 

14. По мере того как Интернет-кафе становятся все популярнее, все больше 
людей хотело бы иметь возможность доступа к своей корпоративной сети 
из любого Интернет-кафе мира. Опишите способ формирования подписан¬ 
ного документа, отправляемого из Интернет-кафе с помощью смарт-карты 
(предполагается, что все компьютеры в Интернет-кафе оборудованы устрой¬ 
ствами чтения смарт-карт). Безопасна ли такая схема? 

15. Возможна ли атака с использованием троянского коня в системе, защищен¬ 
ной перечнями возможностей? 

16. Назовите свойство компилятора С, способное устранить большое количе¬ 
ство дыр в системе безопасности. Почему оно пока не получило более ши¬ 
рокого применения? 

17. При удалении файла его блоки, как правило, возвращаются в список сво¬ 
бодных блоков, но их содержимое не стирается. Как вы полагаете, будет ли 
хорошей идеей, если операционная система будет очищать каждый блок 
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перед тем, как его освободит? Рассмотрите в вашем ответе факторы без¬ 
опасности и производительности, а также покажите, какой эффект окажет 
данная схема на каждый фактор. 

18. Как можно модифицировать операционную систему ТЕЫЕХ, чтобы избе¬ 
жать проблемы с паролями, описанной в тексте? 

19. Как может паразитический вирус 

а) гарантировать, что он будет выполнен, прежде чем выполнится заражен¬ 
ная им программа; 

б) и вернуть управление зараженной программе после того, как он выпол¬ 
нит свои функции? 

20. Некоторые операционные системы требуют, чтобы разделы диска начина¬ 
лись в начале дорожки диска. Как это облегчает жизнь вирусу, заражающе¬ 
му загрузочный сектор? 

21. Измените программу в листинге 9.4 так, чтобы она находила вместо испол¬ 
няемых файлов все программы на языке С. 

22. Вирус на рис. 9.10, г зашифрован. Как может аналитик из антивирусной ла¬ 
боратории определить, какая часть файла представляет собой ключ к шиф¬ 
ру, чтобы расшифровать его и восстановить исходный текст вируса? Что 
может сделать автор вируса для усложнения этой задачи? 

23. Вирус на рис. 9.10, в содержит программы сжатия и распаковки. Распаков¬ 
щик необходим для распаковки и запуска вируса. Для чего нужен запаков¬ 
щик? 

24. Назовите один недостаток полиморфного шифрующегося вируса с точки 
зрения автора вируса. 

25. Часто можно встретить следующую инструкцию для восстановления от ви¬ 
русной атаки: 

а) загрузите зараженную систему; 

б) заархивируйте все файлы на внешний носитель; 

в) отформатируйте диск программой /сіізіі; 

г) переустановите операционную систему с оригинального СО-КОМ; 

д) перезагрузите файлы с внешнего носителя. 

Назовите две серьезные ошибки данной инструкции. 

26. Могут ли в операционной системе ЕПМІХ существовать вирусы-компаньо¬ 
ны (вирусы, которые не модифицируют существующие файлы)? Если да, 
то как? Если нет, то почему? 

27. В чем заключается различие между вирусом и червем? Как они размножа¬ 
ются? 

28. Для распространения программ или программных обновлений часто исполь¬ 
зуются самораспаковывающиеся архивы, содержащие один или несколько 
запакованных файлов и программу распаковки. Рассмотрите влияние при¬ 
менения данной техники на безопасность. 
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29. На некоторых машинах команда 5НК, используемая в листинге 9.6, запол¬ 
няет неиспользуемые биты нулями, на других машинах для этого исполь¬ 
зуется знаковый бит. Имеет ли значение, какой тип команды сдвига ис¬ 
пользуется для корректности программы в листинге 9.6? Если да, то которая 
команда лучше? 

30. Представьте информацию о владельцах и разрешениях, показанную в лис¬ 
тинге каталога операционной системы НМХ, в виде матрицы защиты. При¬ 
мечание : пользователь азт является членом сразу двух групп: изегз и сіеѵеі, 
а пользователь^® является членом только одной группы изегз. Оба пользо¬ 
вателя и обе группы следует представить в виде доменов, так что матрица 
должна иметь четыре строки (по одной для каждого домена) и четыре столб¬ 
ца (по одной для каждого файла). 


-ГМ-Г--Г-- 2 

дтѵѵ 

-гмхг-хг-х 1 

азк 

-гм-гм-1 

азк 

-гм-г-1 

а эн 


и$ег$ 908 Мау 26 16:45 РРР-МоГе$ 

сіеѵеі 432 Мау 13 12:35 ргоді 

изегз 50094 Мау 30 17:51 ргодесіЛ 

сіеѵеі 13124 Мау 31 14:30 зрІазИ.діГ 


31. Представьте информацию о владельцах и разрешениях, показанную в лис¬ 
тинге каталога в предыдущей задаче, в виде АСЬ-списка. 

32. Модифицируйте АСЬ-список для одного файла, чтобы предоставить или 
запретить доступ, который не может быть выражен с помощью системы шах, 
использующейся в ІЖІХ. Объясните сделанные изменения. 

33. Чтобы обеспечить возможность проверки того, что апплет был подписан 
доверенным производителем, производитель апплета может включить в него 
сертификат, подписанный доверенной третьей стороной, содержащий от¬ 
крытый ключ. Однако, чтобы прочитать сертификат, пользователю нужен 
открытый ключ доверенной третьей стороны. Этот ключ может быть под¬ 
твержден четвертой доверенной стороной, но тогда пользователю понадо¬ 
бится и этот открытый ключ. Похоже, что конца у этого метода не видно, 
тем не менее существующие браузеры пользуются им. Как это работает? 

34. В матрице, управляющей доступом, ряды означают домены, а колонки — 
объекты. Что произойдет, если один объект нужен сразу в двух доменах? 

35. В данной главе обсуждались два различных механизма защиты: перечни 
возможностей и списки управления доступом. Какой из этих двух механиз¬ 
мов может быть применен для каждой из следующих проблем: 

а) Кен хочет, чтобы его файлы могли читать все, кроме его напарника по 
офису; 

б) Митч и Стив хотят вместе пользоваться некоторыми секретными файлами; 

в) Линда хочет сделать открытыми некоторые из своих файлов. 

36. В схеме перечней возможностей системы АшоеЬа пользователь может по¬ 
просить сервер создать новый элемент перечня возможностей с меньшими 
правами, который затем он может передать своему другу. Что произойдет, 
если друг попросит сервер еще более сократить права, чтобы он смог пере¬ 
дать новый элемент перечня возможностей кому-то еще? 
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37. На рис. 9.22 от процесса В к объекту 1 нет стрелки. Будет ли допустима 
такая стрелка? Если нет, то какому правилу она противоречит? 

38. На рис. 9.22 нет стрелки от объекта 2 к процессу Л. Будет ли допустима 
такая стрелка? Если нет, то какому правилу она противоречит? 

39. Если бы в схеме на рис. 9.22 были разрешены сообщения между процессами, 
какие правила следовало бы для них установить? В частности, для процесса В: 
каким процессам мог бы он посылать сообщения, а каким нет? 

40. Рассмотрите стеганографическую систему на рис. 9.25. Каждый пиксел мо¬ 
жет быть представлен в пространстве цветов как точка в 3-мерной системе 
с осями К, О и В. Используя это пространство, объясните, что происходит 
с цветовым разрешением при использовании стеганографии. 

41. Текст на нормальном человеческом языке в формате А5СІІ с помощью раз¬ 
личных алгоритмов сжатия может быть сжат, по меньшей мере, на 50 %. 
Учитывая это, сколько текста в формате А5СІІ вместит в себя графическое 
изображение размером 1600 х 1200 пикселов, если использовать все тот же 
метод стеганографии? Насколько увеличится размер изображения в резуль¬ 
тате применения данного метода (предполагается, что шифрование не при¬ 
меняется, или шифрование не увеличивает размеров данных)? Чему равна 
эффективность данной схемы, то есть отношение полезной нагрузки к об¬ 
щему числу передаваемых байтов? 

42. Предположим, что тесно связанная группа политических диссидентов, жи¬ 
вущих в государстве с репрессивным режимом, использует стеганографию, 
чтобы посылать во внешний мир сообщения о положении в их стране. Пра¬ 
вительство знает об этом и борется с группой, посылая поддельные изобра¬ 
жения, содержащие фальшивые стеганографические сообщения. Как могут 
диссиденты попытаться помочь людям отличить настоящие сообщения от 
фальшивых? 

43. Напишите пару сценариев оболочки для отправки и получения текстового 
сообщения по тайному каналу в операционной системе ІЖІХ. ( Подсказка: 
используйте для тайного сигнала время выполнения процесса. Команда зіеер 
гарантированно работает в течение минимального времени, указанного в ка¬ 
честве ее аргумента, а команда рз может использоваться для просмотра всех 
процессов.) 

44. Напишите пару программ на С или на языке сценариев оболочки для от¬ 
правки и получения сообщения по тайному каналу в операционной системе 
ІЖІХ. Подсказка : бит разрешения файла может быть виден, даже если любой 
доступ к файлу запрещен, а команда или системный вызов зіеер гарантиро¬ 
ванно создает задержку на определенный интервал времени, указанного в ка¬ 
честве аргумента. Измерьте скорость передачи данных в простаивающей 
системе. Затем искусственно создайте значительную нагрузку, запустив 
множество фоновых процессов, и снова измерьте скорость передачи данных. 




Глава 10 

Рассмотрение конкретных 
случаев: ІШІХ и Ыпих 

В предыдущих главах мы познакомились с принципами многих операционных 
систем, с абстракциями, алгоритмами и общими методами. Теперь настало время 
взглянуть на некоторые конкретные системы, чтобы увидеть, как эти принципы 
применяются в реальном мире. Мы начнем наше изучение примеров с операцион¬ 
ной системы ІЖІХ, так как она работает на больших типах компьютеров, чем лю¬ 
бая другая операционная система. Система ІЖІХ доминирует на рабочих станци¬ 
ях старших моделей и серверах, но она также используется на различных системах, 
от ноутбуков до суперкомпьютеров. Разработка этой операционной системы была 
подчинена строгому следованию определенной цели, и, несмотря на свой возраст, 
она до сих пор современна и элегантна. Система ІЖІХ иллюстрирует множество 
важных принципов построения операционных систем, многие из которых были 
позаимствованы другими операционными системами. 

Наше обсуждение системы ІЖІХ мы начнем с ее истории и пути развития. За¬ 
тем будет предоставлен общий обзор системы, который должен будет дать пред¬ 
ставление о том, как она работает. Этот обзор особенно важен для читателей, зна¬ 
комых только с системой \ѴіпсІо\ѵ5, так как последняя скрывает от пользователя 
практически все детали системы. Хотя графические интерфейсы могут быть край¬ 
не удобными для начинающих пользователей, они обладают низкой гибкостью 
и не дают представления о том, как работает система. 

Затем мы подойдем к сердцу этой главы, к изучению процессов управления 
памятью, ввода-вывода, файловой системы и безопасности в системе ІЖІХ. Для 
каждой темы мы сначала обсудим фундаментальные понятия, затем системные 
вызовы и, наконец, методы реализации. 

Одна из проблем, с которой мы столкнемся, заключается в том, что существует 
множество клонов и версий системы ІЖІХ, включая АІХ, В5Э, 1В5Э, НР-ІЗХ, 
Ілпих, МІШХ, 05Р/1, 5СО ІЖІХ, Зузіеш V, Зоіагіз, ХЕЙПХ, а также многие дру¬ 
гие, к тому же каждая из них распадается на свои подверсии. К счастью, фунда¬ 
ментальные принципы и системные вызовы практически для всех этих систем во 
многом совпадают. Более того, сходными являются общие стратегии реализации, 
алгоритмы и структуры данных, хотя имеются некоторые различия. В данной гла¬ 
ве при обсуждении реализации будет приведено несколько примеров, в первую 
очередь системы 4.4В5Э (составляющей основу для РгееВЗЭ), Зузіеш V Кеіеазе 4, 
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и Ілпих. Дополнительные сведения о различных вариантах системы 1/МІХ можно 
найти в [22,132, 227, 230, 252, 334]. 


История ІШІХ 

У операционной системы ЕПМІХ долгая и очень интересная история, поэтому с нее 
мы и начнем наше знакомство с этой системой. То, что началось как развлечение 
одного молодого исследователя, стало индустрией с оборотом во много миллионов 
долларов, в которую включились университеты, многонациональные корпорации, 
правительства и международные организации. На следующих страницах мы рас¬ 
смотрим, как разворачивалась эта история. 

ІШІСЗ 

В 40-е и 50-е годы все компьютеры были персональными компьютерами, по край¬ 
ней мере, в следующем смысле: в те времена обычное использование компьютера 
заключалось в том, что пользователь записывался на определенный час, и вся ма¬ 
шина на этот период оказывалась в его распоряжении. Физические размеры этих 
компьютеров были огромными, но работать на таком компьютере в каждый мо¬ 
мент времени мог тогда только один пользователь (программист). Когда на смену 
этим машинам в 60-е годы пришли пакетные системы, программист стал приносить 
в машинный зал задание в виде колоды перфокарт. Если накапливалось достаточ¬ 
ное количество заданий, оператор копировал их на магнитную ленту в единый па¬ 
кет. От пробивки перфокарт до получения программистом распечатки проходило 
около часа или более. При такой схеме на отладку программ уходило очень много 
времени, так как всего одна не там набитая запятая могла привести к потере про¬ 
граммистом нескольких часов. 

Чтобы как-то усовершенствовать существовавшую схему, которую практичес¬ 
ки все считали неудовлетворительной и непродуктивной, в Дартмутском коллед¬ 
же и Массачусетсском технологическом институте были изобретены системы раз¬ 
деления времени. Дартмутская система, в которой работал только ВА5ІС, имела 
кратковременный коммерческий успех, после чего она полностью исчезла. Систе¬ 
ма Массачусетсского технологического института, СТ55, была универсальной си¬ 
стемой, получившей колоссальный успех в научных кругах. За короткое время ис¬ 
следователи из Массачусетсского технологического института объединили усилия 
с лабораторией Веіі ЬаЬз и корпорацией Сепегаі Еіесігіс (в те времена Сепегаі 
Еіесігіс производили компьютеры) и начали разработку системы второго поколе¬ 
ния МШТПСЗ (МІ/ЕТірІехесІ Іпіогшаііоп апсі СотриІіп§ Зегѵісе — мультиплекс¬ 
ная информационная и вычислительная служба), уже обсуждавшейся в главе 1. 

Хотя лаборатория Веіі ЕаЬз была одним из основополагающих партнеров проек¬ 
та МІ/ЕТІСЗ, она вскоре вышла из него, в результате чего один из исследователей 
этой лаборатории, Кен Томпсон, оказался в ситуации поиска новых интересных 
дел. В конце концов, он решил сам написать (на ассемблере) усеченный вариант 
системы МИЕТІС5, для чего у него был списанный мини-компьютер РОР-7. Не¬ 
смотря на крошечные размеры РОР-7, система Томпсона работала и позволяла 
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Томпсону продолжать разработки новой операционной системы. Впоследствии 
еще один исследователь лаборатории Веіі БаЪз, Брайан Керниган, как-то в шутку 
назвал эту систему ІЖІС5 (ІЖірІехесІ Іпіогтаііоп апсі СотриІіп§ Зегѵісе — при¬ 
митивная информационная и вычислительная служба). Несмотря на все калам¬ 
буры и шутки на тему о кастрированной системе МШЛТС5 (кое-кто предлагал 
назвать систему Томпсона ЕІЖІІСН5, то есть евнухом), кличка, данная Кернига- 
ном, прочно пристала к новой системе, хотя написание этого слова стало слегка 
короче, при том же произношении, превратившись в ІЖІХ. 

РОР-11 ІІМХ 

Работа Томпсона произвела на его коллег из лаборатории Веіі БаЬз столь сильное 
впечатление, что вскоре к нему присоединился Деннис Ритчи, а чуть позднее и весь 
его отдел. На это время приходятся два технологических усовершенствования. 
Во-первых, система ІЖІХ была перенесена с устаревшей машины РОР-7 на бо¬ 
лее современные компьютеры РОР-11/20, а позднее на РОР-11/45 и РОР-11/70. 
Последние две машины доминировали в мире мини-компьютеров в течение боль¬ 
шей части 70-х годов. Компьютеры РОР-11/45 и РОР-11/70 представляли собой 
мощные по тем временам машины с большой физической памятью (256 Кбайт 
и 2 Мбайт соответственно). Кроме того, они обладали аппаратной защитой памя¬ 
ти, что позволяло поддерживать одновременную работу нескольких пользовате¬ 
лей. Однако это были 16-разрядные машины, и это ограничивало адресное про¬ 
странство процессов 64 Кбайт для команд и 64 Кбайт для данных, несмотря на то, 
что у этих машин физической памяти было значительно больше 64 Кбайт 1 . 

Второе усовершенствование касалось языка, на котором писалась операцион¬ 
ная система ІЖІХ. Уже давно стало очевидно, что необходимость переписывать 
всю систему заново для каждой новой машины — занятие отнюдь не веселое, по¬ 
этому Томпсон решил переписать ІЖІХ на языке высокого уровня, который он 
сам специально разработал и назвал языком В. Язык В представлял собой упро¬ 
щенную форму языка ВСРБ (который, в свою очередь, был упрощенным языком 
СРБ, подобно РБ/1, никогда не работавшем). Эта попытка оказалась неудачной 
из-за слабостей языка В, в первую очередь, из-за отсутствия в нем структур дан¬ 
ных. Тогда Ритчи разработал следующий язык, явившийся преемником языка В, 
который, естественно, получил название С, и написал для него прекрасный ком¬ 
пилятор. Вместе Томпсон и Ритчи переписали ІЖІХ на С. Язык С оказался как 
раз тем языком, который и был нужен в то время, и он сохраняет лидирующие по¬ 
зиции в области системного программирования до сих пор. 

В 1974 г. Ритчи и Томпсон опубликовали ставшую важной вехой в истории 
компьютеров статью об операционной системе ІЖІХ [275]. За работу, описанную 
в данной статье, им позднее ассоциацией по вычислительной технике АСМ была 
присуждена престижная премия Тьюринга [274, 330]. Публикация этой статьи 
привела к тому, что многие университеты выстроились в очередь в лабораторию 
Веіі БаЬз за копией системы ІЖІХ. Корпорация АТ&Т, являвшаяся учредителем 


1 Точнее, у этих машин было одно общее 64-килобайтное адресное пространство и для команд, и для 
данных. Аналоги этих машин в СССР назывались СМ-4 и СМ-1420. — Примеч. перев. 
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лаборатории Веіі ЬаЬз, была в то время регулируемой монополией и ей не разре¬ 
шалось заниматься компьютерным бизнесом, поэтому она не возражала против 
того, чтобы университеты получали лицензии на право использования системы 
ІЖІХ за умеренную плату. 

По случайному стечению обстоятельств, которые часто формируют историю, 
машина РЭР-11 использовалась на факультетах кибернетики практически каждого 
университета, а операционные системы, с которыми поставлялись эти компьютеры, 
профессоры и студенты считали ужасными. Операционная система ІЖІХ быстро 
заполнила имевшийся вакуум, не в последнюю очередь также благодаря тому, что 
система поставлялась с полным комплектом исходных текстов, поэтому новые 
владельцы системы могли без конца подправлять и совершенствовать ее. Опера¬ 
ционной системе ІЖІХ было посвящено множество научных симпозиумов, на них 
докладчики рассказывали о скрытых ошибках в ядре, которые им удалось обнару¬ 
жить и исправить. Австралийский профессор Джон Лайонс написал к исходному 
тексту системы ІЖІХ комментарий стилем, обычно использующимся в трактатах 
о Джеффри Чосере или Вильяме Шекспире [211]. Книга описывала систему ІЖІХ 
Ѵегзіоп 6, названную так потому, что эта версия операционной системы была опи¬ 
сана в шестом издании руководства программиста ІЖІХ Рго§гаттег’з Мапиаі. 
Исходный текст системы состоял всего из 8200 строк на С и 900 строк ассембле¬ 
ра. В результате новые идеи и усовершенствования системы распространялись 
с огромной скоростью. 

Через несколько лет Ѵегзіоп 6 сменила Ѵегзіоп 7, которая стала первой пе¬ 
реносимой версией операционной системы ІЖІХ (она работала как на машинах 
РИР-11, так и на ІпІегсІаІа 8/32). Эта версия системы уже состояла из 18 800 строк 
на С и 2100 ассемблерных строк. На Ѵегзіоп 7 выросло целое поколение студен¬ 
тов, которые, закончив свои учебные заведения и начав работу в промышленнос¬ 
ти, в значительной степени содействовали дальнейшему распространению систе¬ 
мы ІЖІХ. К середине 80-х операционная система ІЖІХ широко применялась на 
мини-компьютерах и инженерных рабочих станциях самых различных произво¬ 
дителей. Многие компании даже приобрели лицензии на исходные тексты, что¬ 
бы производить свои версии системы ІЖІХ. Одной из таких компаний была не¬ 
большая начинающая фирма МісгозоЛ, в течение нескольких лет продававшая 
Ѵегзіоп 7 под именем ХЕЫІХ, пока ее интересы не повернулись в другую сторону. 

Переносимая система ІІЫІХ 

После того как система ІЖІХ была переписана на языке высокого уровня С, задача 
переноса ее на новые машины стала значительно более простым делом. Для перено¬ 
са системы сначала требуется написать для новой машины компилятор с языка С. 
Затем для устройств ввода-вывода новой машины, таких как терминалы, принтеры 
и диски, нужно написать драйверы устройств. Хотя драйвер может быть написан 
и на С, его нельзя просто перекомпилировать на новой машине и запустить на ней, 
поскольку нет двух одинаково работающих дисков. Наконец, требуется перепи¬ 
сать заново, как правило, на ассемблере, небольшое количество машинно-зависи¬ 
мого кода, например обработчики прерываний и процедуры управления памятью. 
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Первым компьютером, на который была перенесена с машины РОР-11 опера¬ 
ционная система ЕПМІХ, был мини-компьютер ІШегсІаіа 8/32. При этом выясни¬ 
лось следующее: система ЕПМІХ неявно предполагала, что целые числа должны 
быть 16-разрядными, адреса также состоять из 16 бит (в результате чего макси¬ 
мальный размер программы ограничивался размером 64 Кбайт) и что у компью¬ 
тера имеется ровно три регистра для хранения важных переменных. Ни одно из 
этих предположений не было справедливым для мини-компьютера Іпіегсіаіа 8/32, 
поэтому для того, чтобы сделать систему ІЖІХ действительно переносимой, при¬ 
шлось немало потрудиться. 

Другая проблема заключалась в том, что хотя компилятор Ритчи был быст¬ 
рым и формировал хороший объектный код, он мог создавать только объект¬ 
ный код РОР-11. Вместо того чтобы написать новый компилятор специально для 
Іпіегсіаіа 8/32, Стив Джонсон из все той же лаборатории Веіі ЬаЬз разработал 
и реализовал переносимый компилятор языка С. Этот компилятор можно было 
настроить на создание объектного кода для практически любой машины, для чего 
требовался умеренный объем работ. В течение нескольких лет почти все ком¬ 
пиляторы языка С, кроме компиляторов для машин РОР-11, основывались на 
компиляторе Джонсона, что значительно помогло распространению системы 
ІЖІХ на новые компьютеры. 

Процесс переноса операционной системы ІЖІХ на мини-компьютер Іпіег- 
сіаіа 8/32 шел медленно, так как вся работа должна была производиться на един¬ 
ственной в лаборатории машине, на которой работала система ЕПМІХ, на РОР-11. 
Однако случилось так, что компьютер РОР-11 оказался на пятом этаже лаборато¬ 
рии, тогда как Іпіегсіаіа 8/32 был установлен на первом этаже. Создание новой 
версии системы означало ее компиляцию на пятом этаже и запись на магнитную 
ленту, которая физически переносилась на первый этаж, чтобы посмотреть, рабо¬ 
тает ли она. Уже через несколько месяцев подобной работы у разработчиков по¬ 
явился сильный интерес к возможности соединения этих двух машин электрон¬ 
ным способом. Вся работа с сетью в системе ЕПМІХ началась именно с соединения 
этих двух машин. После Іпіегсіаіа система ІЛМІХ была перенесена на ѴАХ, а затем 
и на другие компьютеры. 

После того как в 1984 году правительство США разделило корпорацию АТ&Т, 
компания получила законную возможность инвестировать средства в компью¬ 
терную промышленность, что она и сделала. Вскоре после этого компания АТ&Т 
выпустила на рынок первый коммерческий вариант системы ЕПМІХ, Зузіет III. 
Ее выход на рынок был не очень успешным, поэтому через год она была заменена 
улучшенной версией, Зузіет V. Что случилось с Зузіет IV, до сих пор остает¬ 
ся одной из неразгаданных тайн компьютерного мира. Оригинальную систему 
Зузіет V впоследствии сменили выпуски 2,3 и 4 все той же Зузіет V, каждый по¬ 
следующий выпуск более сложный и громоздкий, чем предшествующий. В про¬ 
цессе усовершенствований оригинальная идея, лежащая в основе системы ЕПМІХ 
и заключающаяся в простоте и элегантности системы, была в значительной мере 
утрачена. Хотя группа Ритчи и Томпсона позднее выпустила 8-ю, 9-ю и 10-ю редак¬ 
ции системы ЕПМІХ, они не получили широкого распространения, так как компа¬ 
ния АТ&Т все свои усилия на рынке вкладывала в продажу версии Зузіет V. 
Однако некоторые идеи из 8-й, 9-й и 10-й редакции системы в конце концов были 
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включены в Зузіет V. Наконец, компания АТ&Т решила, что хочет быть телефон¬ 
ной компанией, а не компьютерной фирмой и в 1993 году продала весь свой биз¬ 
нес, связанный с системой ІШІХ, корпорации Ыоѵеіі, которая, в свою очередь, 
в 1995 году перепродала его компании 8 ап Га Сгиг ОрегаГіоп. К этому времени ста¬ 
ло практически неважным, кому принадлежит этот бизнес, так как почти у всех 
основных компьютерных компаний уже были лицензии. 


Вегкеіеу ІШІХ 

Калифорнийский университет в Беркли был одним из многих университетов, 
приобретших ІІМХ Ѵегзіоп 6 практически с момента ее выхода. Поскольку с систе¬ 
мой поставлялся полный комплект исходных текстов, университет мог существен¬ 
но модифицировать систему. При финансовой поддержке управления перспектив¬ 
ного планирования научно-исследовательских работ АКРА (Айѵапсесі КезеагсЬ 
Рго]есІ5 А^епсу) при Министерстве обороны США университет в Беркли разра¬ 
ботал и выпустил улучшенную версию операционной системы ІШІХ для мини¬ 
компьютера РБР-ІІ, названую 1В5В (Рігзі Вегкеіеу Зоіілѵаге ОізігіЬиііоп — про¬ 
граммное изделие Калифорнийского университета, 1-я версия). Вслед за этой 
магнитной лентой вскоре появилась 2В50, также для РБР-11. 

Более важным событием был выпуск версии ЗВ5Б и ее преемника 4В50, уже 
рассчитанных на 32-разрядные машины ѴАХ. Хотя компания АТ&Т распростра¬ 
няла свою собственную версию для ѴАХ, называвшуюся 32Ѵ, по существу, это 
была Ѵегзіоп 7. В противоположность ей система 4В50 (включая 4.1ВЗО, 4.2В50, 
4.3В50 и 4.4В50) содержала большое количество усовершенствований. Важней¬ 
шими из них были использование виртуальной памяти и страничная подкачка 
файлов, что позволяло создавать программы, большие по размеру, чем физическая 
память. Другое изменение заключалось в поддержке имен файлов длиной более 
14 символов. Реализация файловой системы также была изменена, благодаря 
чему работа с файловой системой стала существенно быстрее. Более надежной 
стала обработка сигналов. В 4-й версии Вегкеіеу ІШІХ появилась поддержка сетей, 
в результате чего используемый в 4ВЗБ протокол ТСР/ІР стал стандартом де-фак¬ 
то в мире ІШІХ, а позднее и в Интернете, в котором преобладают серверы на базе 
системы ІШІХ. 

Университет в Беркли также добавил значительное количество утилит для 
системы ІШІХ, включая новый редактор ѵі и новую оболочку сзк, компиляторы 
языков Разсаі и Ілзр и многое другое. Все эти усовершенствования привели к тому, 
что многие производители компьютеров (Зип МісгозузГетз, ИЕС и другие) стали 
основывать свои версии системы ІШІХ на Вегкеіеу ІШІХ, а не на «официальной» 
версии компании АТ&Т, ЗузГеш V. В результате Вегкеіеу ІШІХ получила широ¬ 
кое распространение в академических и исследовательских кругах. Дополнитель¬ 
ные сведения о системе Вегкеіеу ІШІХ см. [230]. 

Стандартная система ІШІХ 

К концу 80-х широкое распространение получили две различные и в чем-то не¬ 
совместимые версии системы ІШІХ: 4.3В5Б и Зузіеш V Кеіеазе 3. Кроме того, 
практически каждый производитель добавлял свои нестандартные усовершенство- 




История ІІЫІХ 


741 


вания. Этот раскол в мире ІІЫІХ, вместе с тем фактом, что стандарта на формат 
двоичных программ не было, сильно замедлил коммерческое признание операци¬ 
онной системы ІІЫІХ. Производители программного обеспечения не могли напи¬ 
сать пакет программ для системы ІІЫІХ так, чтобы он гарантированно мог быть 
запущен на любой системе ІІЫІХ (как, например, это делалось в системе М5-Э05). 
Различные попытки стандартизации системы ІІЫІХ провалились с самого нача¬ 
ла. Например, корпорация АТ&Т выпустила стандарт 8ѴГО (Зузіет V Іпіегіасе 
ЭейпШоп — описание интерфейса ІІЫІХ Зузіеш V), в котором определялись все 
системные вызовы, форматы файлов и т. д. Этот документ был попыткой постро¬ 
ить в одну шеренгу всех производителей ІІЫІХ Зузіет V, но он не оказал никако¬ 
го влияния на вражеский лагерь (ВЗЭ), который просто проигнорировал его. 

Первая попытка примирить два варианта системы ІІЫІХ была предпринята при 
содействии Совета по стандартам при Институте инженеров по электротехнике 
и электронике ІЕЕЕ Зіапсіагсі Воагск, глубокоуважаемой и, что еще важнее, нейт¬ 
ральной организации. В этой работе приняли участие сотни людей из промышлен¬ 
ности, академических и правительственных организаций. Коллективное название 
данного проекта — Р05ІХ. Первые три буквы этого сокращения означали РогіаЫе 
ОрегаГіщ* Зузіеш — переносимая операционная система. Буквы IX в конце слова 
были добавлены, чтобы имя проекта выглядело юниксообразно. 

После большого количества высказанных аргументов и контраргументов, оп¬ 
ровержений и опровергнутых опровержений, комитет РОЗІХ выработал стандарт, 
известный как 1003.1. Этот стандарт определяет набор библиотечных процедур, 
которые должна предоставлять каждая соответствующая данному стандарту систе¬ 
ма ІІЫІХ. Большая часть этих процедур обращается к системному вызову, но неко¬ 
торые из них могут быть реализованы вне ядра. Типичными процедурами являются 
о реп, геасі и /огк. Идея стандарта РОЗІХ заключается в том, что производитель 
программного обеспечения при написании программы использует только процеду¬ 
ры, описанные в стандарте 1003.1, таким образом, гарантируя, что эта программа бу¬ 
дет работать на любой версии системы ІІЫІХ, поддерживающей данный стандарт. 

Хотя большинство комитетов по стандартам, как правило, создают нечто ужас¬ 
ное, сплошь состоящее из компромиссов, стандарт 1003.1 заметно отличается от 
общего правила в лучшую сторону, особенно если учитывать большое число заин¬ 
тересованных сторон, принимавших участие в его разработке. Вместо того чтобы 
принять за точку отсчета объединение множеств всех свойств Зузіеш V и ВЗЭ 
(норма для большинства комитетов по стандартам), комитет ІЕЕЕ взял за основу 
пересечение множеств. То есть в первом приближении дело обстоит так: если ка¬ 
кое-либо свойство присутствовало как в Зузіет V, так и в ВЗЭ, то оно включалось 
в стандарт. В противном случае это свойство в стандарт не включалось. В резуль¬ 
тате применения такого алгоритма стандарт 1003.1 сильно напоминает прямого 
общего предка систем Зузіеш V и ВЗЭ, а именно Ѵегзіоп 7. От Ѵегяіоп 7 стандарт 
сильнее всего отличается в двух областях: обработке сигналов (что по большей 
части взято из ВЗЭ) и управлению терминалом, что представляет собой ново¬ 
введение. Документ 1003.1 написан так, чтобы как разработчики операционной 
системы, так и создатели программного обеспечения были способны его понять, 
что также ново в мире стандартов, хотя в настоящее время уже полным ходом 
ведется работа по исправлению этого нестандартного для стандартов свойства. 
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Стандарт 1003.1 описывает только системные вызовы, принят также ряд доку¬ 
ментов, стандартизирующих потоки, утилиты, сетевое программное обеспечение 
и многие другие особенности системы ІШІХ. Кроме того, язык С также был стан¬ 
дартизирован Национальным институтом стандартизации США АЫ5І и Между¬ 
народной организацией по стандартизации 150. 

К сожалению, после успешного принятия стандарта, объединившего Зузіеш V 
и В5Б, в мире ІШІХ снова произошел раскол. Группе производителей компьюте¬ 
ров и программного обеспечения, среди которых были такие фирмы, как ІВМ, 
БЕС, Неѵѵіеи-Раскагсі, не понравилось, что корпорация АТ&Т владеет остальной 
частью системы ІШІХ. Поэтому они создали консорциум, названный 05Р (Ореп 
ЗоІІѵѵаге РоипсІаГіоп — Фонд открытого программного обеспечения), чтобы со¬ 
здать систему, удовлетворяющую всем стандартам ІЕЕЕ и другим стандартам, но 
также содержащую множество дополнительных свойств. Среди этих свойств окон¬ 
ная система (XII), графический интерфейс пользователя (МОТІР), распреде¬ 
ленные вычисления (БСЕ, БізІгіЬиІесІ СотриІіп^ ЕпѵігопшепГ — среда распреде¬ 
ленных вычислений), распределенное управление (БМЕ, БізІгіЬиІесІ Мапа^етепі; 
Епѵігоптепі: — среда распределенного управления), а также многое другое. 

В ответ на это корпорация АТ&Т создала собственный консорциум ІЛ (ІШІХ 
Іп(;егпа(;іопа1), чтобы заниматься практически тем же самым. Версия Ш системы 
ІШІХ основывалась на 5узі;ет V. В результате в мире оказалось две мощные про¬ 
мышленные группы, каждая из которых предлагала пользователю свою версию 
системы ІШІХ, так что пользователи нисколько не приблизились к единому стан¬ 
дарту. Однако рынок решил, что ЗузГеш V лучше, чем 05Е, поэтому второй вари¬ 
ант системы постепенно исчез из употребления. У некоторых компаний сейчас есть 
свои версии системы ІШІХ, как, например, система Зоіагіз корпорации 5ип (осно¬ 
ванная на 5уз1;ет V). 

МІЫІХ 

У всех этих систем есть общее свойство: все они большие и сложные, что в оп¬ 
ределенном смысле противоречит оригинальной идее, лежавшей в основе системы 
ІШІХ. Даже если бы все исходные тексты систем продолжали свободно распрост¬ 
раняться, что в большинстве случаев уже давно не так, все равно одному человеку 
просто не под силу понять их. Эта ситуация привела к тому, что автор этой книги 
написал новую юниксоподобную систему, достаточно небольшую, чтобы ее было 
можно понять, с доступным полным исходным текстом, для использования в учеб¬ 
ных целях. Эта система состояла из И 800 строк на С и 800 строк на ассемблере. 
Она была выпущена в 1987 году и функционально практически эквивалентна 
системе Ѵегзіоп 7 ІШІХ, бывшей оплотом большинства факультетов кибернетики 
в эпоху РБР-11. 

Система МШІХ была одной из первых юниксообразных систем, основанной 
на схеме микроядра. Идея микроядра заключается в том, чтобы реализовать как 
можно меньше функций в ядре, в результате чего можно создать надежное и эф¬ 
фективное ядро. Соответственно, задачи управления памятью и файловой систе¬ 
мой были перемещены в процессы пользователя. Ядро в основном обрабатывало 
передачу сообщений между процессами, почти не занимаясь другими задачами. 
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Ядро состояло из 1600 строк на С и 800 ассемблерных строк. По техническим 
причинам, связанным с архитектурой процессора Іпіеі 8088, драйверы устройств 
ввода-вывода (еще 2900 строк на С) также были размещены в ядре. Файловая си¬ 
стема (5100 строк на С) и менеджер памяти (2200 строк на С) работали как два раз¬ 
дельных пользовательских процесса. 

Преимущество микроядер перед монолитными системами заключается в том, 
что устройство микроядра легко понять, да и поддержка системы, основанной на 
микроядре, проще благодаря модульной структуре такой системы. Кроме того, 
перемещение программного обеспечения из ядра в пространство пользователя 
существенно повышает надежность системы, так как сбой процесса, работающего 
в режиме пользователя, способен нанести меньший ущерб, чем сбой компонента 
в режиме ядра. Основной недостаток состоит в несколько меньшей производи¬ 
тельности, связанной с дополнительными переключениями из режима пользова¬ 
теля в режим ядра. Однако производительность — не единственное достоинство 
системы. На всех современных системах ІШІХ оконная система X \Уіпс1о\ѵ5 ра¬ 
ботает в режиме пользователя, в результате чего производительность несколько 
снижается, зато достигается большая модульность (в отличие от системы \Уіпс1о\Ѵ5, 
у которой весь графический интерфейс пользователя расположен в ядре). Среди 
других хорошо известных примеров схемы микроядра того времени можно назвать 
МасЬ [4] и СЬогиз [282]. Обсуждение производительности микроядерной систе¬ 
мы ІШІХ приводится в [42]. 

Уже через несколько месяцев после своего появления система МШІХ стала 
чем-то вроде объекта культа — у нее есть своя конференция, сотр.оз.тіпіх, и более 
40 000 пользователей. Многие пользователи сами стали писать команды и пользо¬ 
вательские программы, так что система МШІХ стала продуктом коллективного 
творчества большого количества пользователей, обменивающихся своими разра¬ 
ботками по Интернету. Она стала прототипом других коллективных работ, появив¬ 
шихся позднее. В 1997 году была выпущена версия 2.0 системы МШІХ. Базовая 
система теперь включала в себя сетевое программное обеспечение, и ее размер 
вырос до 62 200 строк. О системе МШІХ написана книга, содержащая 500 стра¬ 
ниц исходного текста в приложении к книге, а также на поставляемом с книгой 
СИ-КОМ [326]. Исходный текст операционной системы МШІХ можно бесплат¬ 
но получить на \ѵеЬ-сайте ѵѵѵѵѵѵ.с5.ѵи.пІ/~а$1/тіпіх.ЬітІ. 

І_іпих 

В ранние годы развития системы МШІХ и обсуждений этой системы в Интернете 
многие люди просили (а часто требовали) все больше новых и более сложных функ¬ 
ций, и на эти просьбы автор часто отвечал отказом (сохраняя небольшие размеры 
системы, чтобы студенты могли полностью понять ее за один семестр). Эти отка¬ 
зы раздражали многих пользователей. В те времена бесплатной системы РгееВЗИ 
еще не было. Наконец через несколько лет финский студент Линус Торвальдс ре¬ 
шил сам написать еще один клон системы ІШІХ, который он назвал Ілпих. Это 
должна была быть полноценная операционная система, со многими функциями, 
отсутствующими (по намерению авторов) в системе МШІХ. Первая версия опе¬ 
рационной системы Ілпих 0.01 была выпущена в 1991 году. Она была разработана 
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и собрана в системе МШІХ и заимствовала некоторые идеи системы МШІХ, начи¬ 
ная со структуры дерева исходных текстов и кончая структурой файловой системы. 
Однако, в отличие от микроядерной системы МІШХ, Ілпих была монолитной си¬ 
стемой, то есть вся операционная система помещалась в ядре. Размер исходного 
текста составил 9300 строк на С и 950 строк на ассемблере, что приблизительно 
совпадало с версией МІЫІХ. Функционально первая версия Ілпих также практи¬ 
чески почти не отличалась от МШІХ. 

Операционная система Ілпих быстро росла в размерах и впоследствии разви¬ 
лась в полноценный клон ІШІХ с виртуальной памятью, более сложной файло¬ 
вой системой и многими другими добавленными функциями. Хотя изначально 
система Ілпих работала только на процессоре Іпіеі 386 (и даже содержала ассемб¬ 
лерный код 386-й машины посреди процедур на языке С), она была довольно быс¬ 
тро перенесена на другие платформы и теперь работает на широком спектре ма¬ 
шин, как и ІШІХ. Однако одно из основных отличий системы Ілпих от других 
клонов системы ІШІХ заключается в использовании многих специальных осо¬ 
бенностей компилятора §сс, поэтому, чтобы откомпилировать ее стандартным 
АЫ5І С компилятором, потребуется приложить немало усилий. 

Следующим основным выпуском системы Ілпих была версия 1.0, появивша¬ 
яся в 1994 году. Она состояла из 165 000 строк кода и включала новую файло¬ 
вую систему, отображение файлов на адресное пространство памяти и совмести¬ 
мое с В5И сетевое программное обеспечение с сокетами и ТСР/ІР. Она также 
включала многие новые драйверы устройств. Следующие два года выходили вер¬ 
сии с незначительными исправлениями. 

К этому времени операционная система Ілпих стала достаточно совместимой 
с ІШІХ, поэтому в нее было перенесено большое количество программного обес¬ 
печения ІШІХ, что значительно увеличило полезность рассматриваемой системы. 
Кроме того, операционная система Ілпих привлекла большое количество людей, 
которые начали работу над ее совершенствованием и расширением под общим 
руководством Торвальдса. 

Следующий главный выпуск, версия 2.0, вышел в свет в 1996 году. Эта версия 
системы Ілпих состояла из 470 000 строк на С и 8000 строк ассемблерного текста. 
Она включала в себя поддержку 64-разрядной архитектуры, симметричной мно¬ 
гозадачности, новых сетевых протоколов и прочих многочисленных функций. Зна¬ 
чительную часть от общей массы исходного текста составляла внушительная кол¬ 
лекция различных драйверов устройств. Следом за версией 2.0 довольно часто 
выходили дополнительные выпуски. 

В систему Ілпих была перенесена внушительная часть стандартного программ¬ 
ного обеспечения ІШІХ, включая более 1000 утилит, оконную систему X \Ѵіпс1о\ѵк 
и большую часть сетевого программного обеспечения. Кроме того, специально 
для Ілпих было написано два различных графических интерфейса пользователя: 
СИОМЕ и КИЕ. В общем, система Ьіпих выросла в полноценный клон ІШІХ со 
всеми погремушками, какие только могут понадобиться фанату ІШІХ. 

Необычной особенностью Ьіпих является ее бизнес-модель: это свободно распро¬ 
страняющееся программное обеспечение. Ее можно скачать с различных Интернет- 
сайтов, например ѵѵѵѵѵѵ.кегпеі.огд. Система Ілпих поставляется вместе с лицензией, 
разработанной Ричардом Столманом, основателем Фонда бесплатно распростра- 




История ІІЫІХ 


745 


няемых программ Ргее 5оК\ѵаге РоипсІаНоп. Несмотря на то что система Ьіпих 
распространяется бесплатно, эта лицензия, называющаяся СРЬ (СЬШ РиЫіс 
Ьісепзе — общедоступная лицензия), по длине превышает лицензию корпорации 
Місго5оЙ для операционной системы ^іпсіоѵѵз 2000. Она содержит сведения о том, 
что вы можете и чего не можете делать с исходным текстом. Пользователи могут 
свободно использовать, копировать, модифицировать и распространять дальше 
исходные тексты и двоичные файлы. Основной запрет касается отдельной прода¬ 
жи или распространения двоичного кода без исходных текстов. Исходные тексты 
должны либо поставляться вместе с двоичными файлами, либо предоставляться 
по требованию. 

Хотя Торвальдс до сих пор довольно внимательно контролирует ядро системы, 
большое количество программ пользовательского уровня было написано другими 
многочисленными программистами, многие из которых изначально перешли на 
Ьіпих из сетевых сообществ МІШХ, В5И и СЫИ (Ргее ЗоКѵѵаге Роипсіайоп). Од¬ 
нако по мере развития системы Ьіпих все меньшая часть сообщества Ьіпих желает 
ковыряться в исходном тексте (свидетельством тому служат сотни книг, описыва¬ 
ющих, как установить систему Ьіпих и как ею пользоваться, и только несколько 
книг, в которых обсуждается сама система, или как она работает). Кроме того, мно¬ 
гие пользователи Ьіпих теперь предпочитают бесплатному скачиванию системы 
по Интернету покупку одного из СИ-КОМ, распространяемых многочисленны¬ 
ми коммерческими компаниями. На \ѵеЪ-сайте ѵѵѵѵѵѵ.ііпих.огд перечислено более 
50 компаний, продающих различные пакеты Ьіпих. По мере того как все больше 
и больше компаний, занимающихся программным обеспечением, начинают про¬ 
давать свои версии Ьіпих, а все большее число производителей компьютеров по¬ 
ставляют систему Ьіпих со своими машинами, граница между коммерческим и бес¬ 
платным программным обеспечением слегка размывается. 

Интересно отметить, что когда мода на Ьіпих начала набирать обороты, система 
получила поддержку с неожиданной стороны — от корпорации АТ&Т. В 1992 году 
университет в Беркли, лишившись финансирования, решил прекратить разработ¬ 
ку В5И ИШХ с последней версией 4.4В5И (которая впоследствии послужила ос¬ 
новой для РгееВЗИ). Поскольку эта версия не содержала по существу кода АТ&Т, 
университет в Беркли выпустил это программное обеспечение под лицензией от¬ 
крытого исходного кода, которая позволяла всем делать все, что угодно, кроме од¬ 
ной вещи — подавать в суд на университет Калифорнии в Беркли. Корпорация 
АТ&Т, продолжающая контролировать систему ІЖІХ в дополнение к своим основ¬ 
ным занятиям, немедленно отреагировала — можете догадаться, как — подав в суд 
на университет Калифорнии в Беркли. Она мгновенно подала иск против компа¬ 
нии В50І, созданной разработчиками В50 ІЖІХ для упаковки системы и поддерж¬ 
ки продаж (примерно так сейчас поступают компании типа Кесі На! с операцион¬ 
ной системой Ьіпих). Поскольку практически программы АТ&Т не использовались, 
судебное дело основывалось на нарушении авторского права и торговой марки, 
включая такие моменты, как телефонный номер компании В5ВІ 1-800-ІТ5-ІЖІХ. 
Хотя этот спор в конце концов удалось урегулировать без судебного разбиратель¬ 
ства, это не позволило выпустить на рынок РгееВЗО в течение периода, достаточно 
долгого для того, чтобы система Ьіпих успела развиться и упрочить свои позиции. 
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Если бы корпорация АТ&Т не подала судебного иска, то уже где-то году в 1993 
началась бы серьезная борьба между двумя бесплатными версиями системы ІЖІХ, 
распространяющимися с исходными текстами: царствующим чемпионом, систе¬ 
мой В5Б, матерой и устойчивой системой с многочисленными приверженцами в 
академической среде еще с 1977 года, и яростным молодым претендентом, систе¬ 
мой Ыпих, всего лишь двух лет отроду, но уже с растущим числом сторонников 
среди индивидуальных пользователей. Кто знает, чем бы обернулась эта схватка 
двух бесплатных версий системы ІЖІХ? 

Если учитывать эту историю, строгое соответствие стандарту Р05ІХ, а также 
пересечение сообществ пользователей, то не должно показаться удивительным, что 
многие черты системы Ыпих, системные вызовы, программы, библиотеки, алгорит¬ 
мы и внутренние структуры данных очень схожи со своими аналогами в ІЖІХ. 
Например, более 80 % от приблизительно 150 системных вызовов Ыпих представ¬ 
ляют собой точные копии соответствующих системных вызовов в Р05ІХ, В5Б или 
Зузіеш V. Таким образом, в первом приближении большая часть описания систе¬ 
мы ІЖІХ, приведенного в данной главе, также применимо и к Ыпих. В тех местах, 
где ІЖІХ и Ыпих существенно различаются (например, в алгоритме планирова¬ 
ния), это будет специально отмечено, и мы расскажем об обоих вариантах. Там же, 
где серьезных отличий не будет, для краткости мы будем просто описывать опера¬ 
ционную систему ІЖІХ. Следует предупредить читателя, что операционная сис¬ 
тема Ыпих стремительно развивается и тысячи программистов работают над ее 
совершенствованием, поэтому некоторая часть данного материала (основанная на 
версии 2.2), без всякого сомнения, довольно скоро устареет. 


Обзор системы ІІЫІХ 

В этом разделе будет представлено общее введение в операционную систему ІЖІХ, 
а также описано, как ей пользоваться, для читателей, еще не знакомых с этой 
системой. Хотя разные версии системы ІЖІХ различаются в мелких деталях, при¬ 
веденный здесь материал применим ко всем версиям системы. Основное внима¬ 
ние в данном разделе будет уделено тому, как система ІЖІХ выглядит на терми¬ 
нале. Последующие разделы будут посвящены системным вызовом и внутреннему 
устройству системы. 


Задачи ІШІХ 

Операционная система ІЖІХ представляет собой интерактивную систему, раз¬ 
работанную для одновременной поддержки нескольких процессов и нескольких 
пользователей. Она была разработана программистами и для программистов, что¬ 
бы использовать ее в окружении, в котором большинство пользователей являют¬ 
ся относительно опытными и занимаются проектами (часто довольно сложными) 
разработки программного обеспечения. Во многих случаях большое количество 
программистов активно сотрудничают в деле создания единой системы, поэтому 
в операционной системе ІЖІХ есть достаточное количество средств, позволяющих 
программистам работать вместе и управлять совместным использованием общей 
информации. Очевидно, что модель группы опытных программистов, совместно 
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работающих над созданием передового программного обеспечения, существенно 
отличается от модели одиночного начинающего пользователя, сидящего за персо¬ 
нальным компьютером в текстовом процессоре, и это отличие отражено в опера¬ 
ционной системе ІШІХ от начала до конца. 

Чего хотят от операционной системы хорошие программисты? Во-первых, 
большинство хотело бы, чтобы их система была простой, элегантной и непротиво¬ 
речивой. Например, на нижнем уровне файл должен представлять собой просто 
набор байтов. Наличие различных классов файлов для последовательного и про¬ 
извольного доступа, доступа по ключу, удаленного доступа и т. д. (как это реали¬ 
зовано на мэйнфреймах) просто является помехой. А если команда 

15 А* 

означает вывод списка всех файлов, имя которых начинается с буквы «А», то ко¬ 
манда 

гт А* 

должна означать удаление всех файлов, имя которых начинается с буквы «А», а не 
одного файла, имя которого состоит из буквы «А» и звездочки. Эта характеристи¬ 
ка иногда называется принципом наименьшей неожиданности. 

Другое свойство, которое, как правило, опытные программисты желают видеть 
в операционной системе, — это мощь и гибкость. Это означает, что в системе долж¬ 
но быть небольшое количество базовых элементов, которые можно комбинировать 
бесконечным числом способов, чтобы приспособить их для конкретного прило¬ 
жения. Одно из основных правил системы ІШІХ заключается в том, что каждая 
программа должна выполнять всего одну функцию, но делать это хорошо. Таким 
образом, компиляторы не занимаются созданием листингов, так как другие про¬ 
граммы могут лучше справиться с этой задачей. 

Наконец, у большинства программистов сильная неприязнь к бесполезной из¬ 
быточности. Зачем писать сору, когда достаточно ср? Чтобы получить список всех 
строк, содержащих строку «агб» из файла/, программист в операционной системе 
ІШІХ вводит команду 

дгер агй ? 

Противоположный подход состоит в том, что программист сначала запускает 
программу §гер (без аргументов), после чего программа §гер приветствует програм¬ 
миста фразой: «Здравствуйте, я §гер. Я ищу символьные строки в файлах. Введите, 
пожалуйста, искомую строку». Получив строку, программа §гер просит задать имя 
файла. Затем она спрашивает, есть ли еще какие-либо файлы. Наконец она выводит 
листинг итогового задания и спрашивает, все ли верно. Хотя такой тип пользователь¬ 
ского интерфейса, возможно, удобен для начинающих пользователей, он бесконечно 
раздражает опытных программистов. То, что им нужно — это слуга, а не нянька. 

Интерфейсы системы ІШІХ 

Операционную систему ІШІХ можно рассматривать в виде пирамиды (рис. 10.1). 
У основания пирамиды располагается аппаратное обеспечение, состоящее из цен¬ 
трального процессора, памяти, дисков, терминалов и других устройств. На голом 




748 


Глава 10. Рассмотрение конкретных случаев: ШІХ и І_іпих 


«железе» работает операционная система ІІЫІХ. Ее функция заключается в управ¬ 
лении аппаратным обеспечением и предоставлении всем программам интерфейса 
системных вызовов. Эти системные вызовы позволяют программам создавать про¬ 
цессы, файлы и прочие ресурсы, а также управлять ими. 


Интерфейс 

пользователя 


Интерфейс 

библиотечных 

функций 

I 


Интерфейс 

системных 

вызовов 


Пользователи 


Стандартные обслуживающие 
программы (оболочка, 
компиляторы и т. д.) 


Стандартная библиотека 
(ореп, сіозе, геасі, ѵѵгііе, Іогк и т. д.) 


Операционная система 
^NIX (управление процессами, памятью, 
файловая система, ввод-вывод и т. д.) 


Аппаратное обеспечение (центральный процессор, 
память, диски, терминалы и т. д.) 


Режим 

пользователя 


Режим ядра 

_і _ 


Рис. 10.1. Уровни операционной системы ІІЬІІХ 

Программы обращаются к системным вызовам, помещая аргументы в регист¬ 
ры центрального процессора (или иногда в стек) и выполняя команду эмулиро¬ 
ванного прерывания для переключения из пользовательского режима в режим 
ядра и передачи управления операционной системе ІЖІХ. Поскольку на языке С 
невозможно написать команду эмулированного прерывания, этим занимаются 
библиотечные функции, по одной на системный вызов. Эти процедуры написаны 
на ассемблере, но они могут вызываться из программ, написанных на С. Каждая 
такая процедура помещает аргументы в нужное место и выполняет команду эму¬ 
лированного прерывания ТКАР. Таким образом, чтобы обратиться к системному 
вызову геасі, программа на С должна вызвать библиотечную процедуру геасі. Кста¬ 
ти, в стандарте Р05ІХ определен именно интерфейс библиотечных функций, а не 
интерфейс системных вызовов. Другими словами, стандарт Р05ІХ определяет 
библиотечные процедуры, соответствующие системным вызовам, их параметры, 
что они должны делать и какой результат возвращать. В стандарте даже не упоми¬ 
наются фактические системные вызовы. 

Помимо операционной системы и библиотеки системных вызовов, все вер¬ 
сии ІЖІХ содержат большое количество стандартных программ, некоторые из 
них описываются стандартом Р05ІХ 1003.2, тогда как другие могут различаться 
в разных версиях системы ІЖІХ. К этим программам относятся командный про¬ 
цессор (оболочка), компиляторы, редакторы, программы обработки текста и утили¬ 
ты для работы с файлами. Именно эти программы и запускаются пользователем 
с терминала. 

Таким образом, мы можем говорить о трех интерфейсах в операционной систе¬ 
ме ІЖІХ: интерфейсе системных вызовов, интерфейсе библиотечных функций 
и интерфейсе, образованным набором стандартных обслуживающих программ. 
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Хотя именно последний интерфейс большинство пользователей считает системой 
ІІШХ, в действительности он не имеет практически никакого отношения к самой 
операционной системе и легко может быть заменен. 

В некоторых версиях системы ІІШХ, например, этот ориентированный на ввод 
с клавиатуры интерфейс пользователя был заменен графическим интерфейсом 
пользователя, ориентированным на использование мыши, для чего не потребова¬ 
лось никаких изменений в самой системе. Именно эта гибкость сделала систему 
ІІШХ столь популярной и позволила ей пережить многочисленные изменения 
технологии, лежащей в ее основе. 

Оболочка ІІЫІХ 

У многих версий системы ІІШХ имеется графический интерфейс пользователя, 
схожий с популярными интерфейсами, примененными на компьютере МасіпІозЬ 
и впоследствии в системе \Уіп<Зо\У5. Однако истинные программисты до сих пор 
предпочитают интерфейс командной строки, называемый оболочкой (зЬеІІ). По¬ 
добный интерфейс значительно быстрее в использовании, существенно мощнее, 
проще расширяется и не раздражает пользователя необходимостью постоянно хва¬ 
таться за мышь. Ниже будет кратко описана оболочка Бурна (зк). С тех пор было 
написано много других оболочек (кзк, Ъазк и т. д.). Хотя система ІІШХ полностью 
поддерживает графическое окружение (X ^іпскпѵз), даже в этом мире многие про¬ 
граммисты просто создают множество консольных окон и действуют так, как если 
бы у них была дюжина алфавитно-цифровых терминалов, на каждом из которых 
работала бы оболочка. 

Когда оболочка запускается, она инициализируется, а затем печатает на экране 
символ приглашения к вводу (обычно это знак доллара или процента) и ждет, ког¬ 
да пользователь введет командную строку. 

После того как пользователь введет командную строку, оболочка извлекает из 
нее первое слово и ищет файл с таким именем. Если такой файл удается найти, 
оболочка запускает его. При этом работа оболочки приостанавливается на время 
работы запущенной программы. По завершении работы программы оболочка 
снова печатает приглашение и ждет ввода следующей строки. Здесь важно под¬ 
черкнуть, что оболочка представляет собой обычную пользовательскую програм¬ 
му. Все, что ей нужно, — это способность ввода с терминала и вывода на терминал, 
а также возможность запускать другие программы. 

У команд оболочки могут быть аргументы, которые передаются запускаемой 
программе в виде текстовых строк. Например, командная строка 

ср 5 гс сІезБ 

запускает программу ср с двумя аргументами зге и сіезі. Эта программа интерпре¬ 
тирует первый аргумент как имя существующего файла. Она копирует этот файл 
и называет его копию сіезі. 

Не все аргументы обязательно должны быть именами файлов. В строке 
Неасі -20 Ліе 

первый аргумент -20 велит программе кеасі напечатать первые 20 строк файла /Не 
вместо принятых по умолчанию 10 строк. Аргументы, управляющие работой коман- 
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ды или указывающие дополнительные значения, называются флагами или клю¬ 
чами и по соглашению обозначаются знаком тире. Тире требуется, чтобы избежать 
двусмысленности. Так, например, команда 

Неасі 20 Гііе 

вполне законна. Она велит программе кеасі напечатать первые 10 строк файла 20, 
а затем первые 10 строк файла/г/е. Большинство команд системы ІЖІХ могут при¬ 
нимать несколько флагов и аргументов. 

Чтобы было легче указывать группы файлов, оболочка принимает так называ¬ 
емые волшебные символы, иногда называемые также джокерами. Например, сим¬ 
вол звездочки означает все возможные варианты текстовой строки, так что строка 

1 5 *.С 

велит программе Із вывести список всех файлов, имя которых оканчивается на .с. 
Если файлы х.с, у.е и г.с существуют, то данная команда эквивалентна команде 

15 х.с у.е г.с 

Другим джокером является вопросительный знак, который заменяет один лю¬ 
бой символ. Кроме того, в квадратных скобках можно указать множество симво¬ 
лов, из которых программа должна будет выбрать один. Например, команда 

1з [аре]* 

велит программе Із вывести список всех файлов, имя которых начинается с симво¬ 
лов «а», «р» или «е». 

Программа вроде оболочки не должна открывать терминал, чтобы прочитать 
с него или вывести на него строку. Вместо этого запускаемые программы автома¬ 
тически получают доступ к файлу, называемому стандартным устройством вво¬ 
да (зіапсіагсі іприі), и к файлу, называемому стандартным устройством вывода 
(зіапсіагсі оиіриі), а также к файлу, называемому віапсіагсі еггог (стандартное уст¬ 
ройство для вывода сообщений об ошибках). По умолчанию всем трем устрой¬ 
ствам соответствует терминал, то есть клавиатура для ввода и экран для вывода. 
Многие программы в системе ІЖІХ читают данные со стандартного устройства 
ввода и пишут на стандартное устройство вывода. Например, команда 

50ГГ 

вызывает программу зогі, читающую строки с терминала (пока пользователь не 
нажмет комбинацию клавиш СТК1.+0, чтобы обозначить конец файла), а затем сор¬ 
тирует их в алфавитном порядке и выводит результат на экран. 

Стандартные ввод и вывод также можно перенаправить, что является очень 
полезным свойством. Для этого используются символы «<>> и «>» соответственно. 
Разрешается их одновременное использование в одной командной строке. Напри¬ 
мер, команда 

зогі; <іп >оіЛ 

заставляет программу зогі взять в качестве входного файл іп и направить вывод 
в файл оиі. Поскольку стандартный вывод сообщений об ошибках не был перена¬ 
правлен, все сообщения об ошибках будут печататься на экране. Программа, считы- 
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вающая данные со стандартного устройства ввода, выполняющая определенную 
обработку этих данных и записывающая результат в поток стандартного вывода, 
называется фильтром. 

Рассмотрим следующую командную строку, состоящую из трех отдельных 
команд: 

$огі; <іп >іешр; ИеасІ -30 <іешр: гш Гетр 

Сначала запускается программа зогі, которая принимает данные из файла іп 
и записывает результат в файл іетр. Когда она завершает свою работу, оболочка 
запускает программу кеасі, веля ей распечатать первые 30 строк из файла іетр 
на стандартном устройстве вывода, которым по умолчанию является терминал. 
Наконец, временный файл іетр удаляется. 

В системе ІЖІХ часто используются командные строки, в которых первая про¬ 
грамма в командной строке формирует вывод, используемый второй программой 
в качестве входа. В приведенном выше примере для этого использовался времен¬ 
ный файл іетр. Однако система ВГШХ предоставляет более простой способ для 
этого. В командной строке 

$огГ <іп | ЬеасІ -30 

для этого используется вертикальная черта, называемая символом канала. Этот 
символ означает, что вывод программы зогі должен использоваться в качестве вхо¬ 
да для программы кеасі, что позволяет обойтись без явного указания оболочке со¬ 
здать временный файл, а потом удалить его. Набор команд, соединенных симво¬ 
лом канала, называется конвейером и может содержать произвольное количество 
команд. Пример четырехкомпонентного конвейера показан в следующей строке: 

дгер Гег * Л | $огГ | ЬеаС -20 | Гаіі -5 >Гоо 

Здесь в стандартное устройство вывода записываются все строки, содержащие 
строку «Гег» во всех файлах, оканчивающихся на .1, после чего они сортируются. 
Первые 20 строк выбираются программой кеасі, которая передает их программе іаіі, 
записывающей последние пять строк (то есть строки с 16 по 20 в отсортированном 
списке) в файл /оо. Вот пример того, как операционная система ІЖІХ предостав¬ 
ляет основные строительные блоки (фильтры), каждый из которых выполняет 
определенную работу, вместе с механизмом, позволяющим объединять их прак¬ 
тически неограниченными способами. 

ІЖІХ является универсальной многозадачной системой. Один пользователь 
может одновременно запустить несколько программ, каждую в виде отдельного 
процесса. Синтаксис оболочки для запуска фонового процесса состоит в исполь¬ 
зовании символа амперсанда в конце строки. Таким образом, строка 

мс -1 <а >Ь & 

запустит программу подсчета количества слов тс, которая сосчитает число строк 
(флаг -/) во входном файле а и запишет результат в файл Ъ, но будет делать это в 
фоновом режиме. Как только команда введена пользователем, оболочка напечата¬ 
ет символ приглашения к вводу и перейдет в режим ожидания следующей коман¬ 
ды. Конвейеры также могут выполняться в фоновом режиме, например: 

$огі <х | ЬеасІ & 
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Можно одновременно запустить несколько фоновых конвейеров. 

Список команд оболочки может быть помещен в файл, а затем этот файл с ко¬ 
мандами может быть выполнен, для чего нужно запустить оболочку с этим фай¬ 
лом в качестве входного аргумента. Вторая программа оболочки просто выполнит 
перечисленные в этом файле команды одну за другой, точно так же, как если бы 
эти команды вводились с клавиатуры. Файлы, содержащие команды оболочки, 
называются сценариями оболочки. Сценарии оболочки могут присваивать значе¬ 
ния переменным оболочки и затем считывать их. Они также могут запускаться 
с параметрами и, кроме того, использовать конструкции ІГ, Гог, мИіІе и сазе. Таким 
образом, сценарии оболочки представляют собой настоящие программы, написан¬ 
ные на языке оболочки. Существует альтернативная оболочка Вегкіеу С, разра¬ 
ботанная таким образом, чтобы сценарии оболочки (и команды языка вообще) 
выглядели во многих аспектах подобно программам на С. Поскольку оболочка 
представляет собой всего лишь еще одну пользовательскую программу, было на¬ 
писано много различных ее версий. 

Утилиты ШМІХ 

Пользовательский интерфейс ГГШХ состоит не только из оболочки, но также из 
большого числа стандартных обслуживающих программ, называемых также утили¬ 
тами. Грубо говоря, эти программы можно разделить на шесть следующих категорий: 

1. Команды управления файлами и каталогами. 

2. Фильтры. 

3. Средства разработки программ, такие как текстовые редакторы и компи¬ 
ляторы. 

4. Текстовые процессоры. 

5. Системное администрирование. 

6. Разное. 

Стандарт Р05ІХ 1003.2 определяет синтаксис и семантику менее 100 из этих 
программ, в основном относящихся к первым трем категориям. Идея стандарти¬ 
зации данных программ заключается в том, чтобы можно было писать сценарии 
оболочки, которые работали бы на всех системах ІЖІХ. Помимо этих стандарт¬ 
ных утилит, разумеется, существует еще масса прикладных программ, таких как 
\ѵеЬ-браузеры, программы просмотра изображений и т. д. 

Рассмотрим несколько примеров этих утилит, начиная с программ для управ¬ 
ления файлами и каталогами. Команда 

ср а Ь 

копирует файл авЪ,не изменяя исходный файл. Команда 
тѵ а Ь 

напротив, копирует файл а в Ъ, но удаляет исходный файл. В результате она не ко¬ 
пирует файл, а перемещает его. Несколько файлов можно объединить в один при 
помощи команды са(, считывающей все входные файлы и копирующей их один за 




Обзор системы ШІХ 


753 


другим в стандартный выходной поток. Удалить файлы можно командой гт. 
Команда сктосі позволяет владельцу изменить права доступа к файлу. Каталоги 
можно создать командой тМіг и удалить командой гтсііг. Список файлов можно 
вывести на экран, принтер или в файл командой Із. У этой команды множество 
флагов (ключей), управляющих видом формируемого ею листинга. При помощи 
одних флагов можно задать, насколько подробно будет отображаться каждый файл 
(размер, владелец, группа, дата создания), другими флагами задается порядок, 
в котором перечисляются файлы (по алфавиту, по времени последнего изменения, 
в обратном порядке), третья группа флагов позволяет задать расположение спис¬ 
ка файлов на экране и т. д. 

Мы уже рассматривали несколько примеров фильтров: команда @гер извлекает 
из стандартного входного потока или из одного или нескольких файлов строки, 
содержащие определенную последовательность символов. Команда зогС сортиру¬ 
ет входной поток и выводит отсортированные данные в стандартный выходной 
поток. Команда кеасі пропускает сквозь себя первые несколько строк. Команда Саіі, 
напротив, выдает на выходе указанное количество последних строк с входа. Кро¬ 
ме того, стандартом 1003.2 определены такие фильтры, как сиі и разСе, которые 
позволяют вырезать и вставлять в файлы куски текста. Команда осі конвертирует 
(обычно двоичный) вход в АЗСІІ-строку в восьмеричный, десятичный или шест¬ 
надцатеричный формат. Команда іг преобразует символы из верхнего регистра в 
нижний, и наоборот, а команда отформатирует выход для вывода на принтер, по¬ 
зволяя добавлять заголовки, номера страниц и т. д. 

Компиляторы и программные средства включают в себя компилятор с языка С 
сс и программу аг, собирающую библиотечные процедуры в архивные файлы. 

Еще одной важной инструментальной программой является команда таке, ис¬ 
пользуемая для сборки больших программ, исходный текст которых состоит из 
нескольких файлов. Как правило, некоторые из этих файлов представляют собой 
заголовочные файлы, содержащие определения типов, переменных, макросов 
и т. д. Исходные файлы обычно ссылаются на эти файлы с помощью специальной 
директивы компилятора іпсіисіе. Таким образом, два и более исходных файла мо¬ 
гут совместно использовать одни и те же определения. Однако если файл заголов¬ 
ков изменен, необходимо найти все исходные файлы, зависящие от него, и пере¬ 
компилировать их. Задача команды таке заключается в том, чтобы отслеживать, 
какой файл от какого зависит, и автоматически запускать компилятор для тех фай¬ 
лов, которые требуется перекомпилировать. Почти все программы в системе ІЖІХ, 
кроме самых маленьких, компилируются с помощью команды таке. 

Все упоминавшиеся выше команды перечислены еще раз в табл. 10.1 вместе с 
кратким описанием. Во всех версиях операционной системы ІЛЧІХ есть эти про¬ 
граммы, а также многие другие. 


Таблица 10.1. Некоторые утилиты УЫІХ, требуемые стандартом Р05ІХ 

Программа 

Функция 


Конкатенация нескольких файлов в стандартный выходной поток 

Изменение режима защиты файла 

Копирование файлов 

Вырезание колонок текста из файла 


продолжение 
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Таблица 10.1 ( продолжение) 

Программа Функция 

дгер Поиск определенной последовательности символов в файле 

Ьеаб Извлечение из файла первых строк 

Із Распечатка каталога 

таке Компиляция файлов для создания двоичного файла 

тксііг Создание каталога 

осі Шестнадцатеричный дамп файла 

разіе Вставка колонок текста в файл 

рг Форматирования файла для печати 

гт Удаление файлов 

гтсііг Удаление каталога 

зогі Сортировка строк файла по алфавиту 

ІаіІ Извлечение из файла последних строк 

Іг Преобразование символов из одного набора в другой 


Структура ядра 

На рис. 10.1 была показана общая структура системы ІЖІХ. Давайте теперь по¬ 
подробнее рассмотрим ядро системы. Обзор структуры ядра системы ІЖІХ пред¬ 
ставляет собой довольно непростое дело, так как существует множество различ¬ 
ных версий этой системы. Однако, хотя диаграмма на рис. 10.2 описывает ІЖІХ 
4.4ВЗО, она также применима ко многим другим версиям, возможно, с небольши¬ 
ми изменениями в тех или иных местах. 


-1 

Системные вызовы 
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прерывания 
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Сокеты 

Именование 

файла 

Отображение 

адресов 

Страничные 

прерывания 

Обработка 

сигналов 
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и завершение 
процессов 

Необработанный 

телетайп 

Обработанный 

телетайп 

Сетевые 

протоколы 

Файловые 

системы 

Виртуальная 
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процессов 

Аппаратура 


Рис. 10.2. Структура ядра операционной системы ІИ\ІІХ4.4В30 
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Нижний уровень ядра состоит из драйверов устройств и процедуры диспетче¬ 
ризации процессов. Все драйверы системы ІЖІХ делятся на два класса: драйверы 
символьных устройств и драйверы блочных устройств. Основное различие между 
этими двумя классами устройств заключается в том, что на блочных устройствах 
разрешается операция поиска, а на символьных нет. Технически сетевые устрой¬ 
ства представляют собой символьные устройства, но они обрабатываются по-ино¬ 
му, поэтому их, вероятно, правильнее выделить в отдельных класс, как это и было 
сделано на схеме. Диспетчеризация процессов производится при возникновении 
прерывания. При этом низкоуровневая программа останавливает выполнение ра¬ 
ботающего процесса, сохраняет его состояние в таблице процессов ядра и запус¬ 
кает соответствующий драйвер. Кроме того, диспетчеризация процессов произво¬ 
дится также, когда ядро завершает свою работу и пора снова запустить процесс 
пользователя. Программа диспетчеризации процессов написана на ассемблере и 
представляет собой отдельную от процедуры планирования программу. 

В более высоких уровнях программы отличаются в каждом из четырех «столб¬ 
цов» диаграммы. Слева располагаются символьные устройства. Они могут исполь¬ 
зоваться двумя способами. Некоторым программам, таким как текстовые редак¬ 
торы ѵі и етасз, требуется каждая нажатая клавиша без какой-либо обработки. Для 
этого служит ввод-вывод с необработанного терминала (телетайпа). Другое про¬ 
граммное обеспечение, например оболочка (хй), принимает на входе уже готовую 
текстовую строку, позволяя пользователю редактировать ее, пока не будет нажата 
клавиша ЕМТЕК. Такое программное обеспечение пользуется вводом с терминала 
в обработанном виде и дисциплинами линии связи. 

Сетевое программное обеспечение часто бывает модульным, с поддержкой мно¬ 
жества различных устройств и протоколов. Уровень выше сетевых драйверов вы¬ 
полняет своего рода функции маршрутизации, гарантируя, что правильный пакет 
направляется правильному устройству или блоку управления протоколами. Боль¬ 
шинство систем ІЖІХ содержат в своем ядре полноценный маршрутизатор Ин¬ 
тернета, и хотя его производительность ниже, чем у аппаратного маршрутизатора, 
эта программа появилась раньше современных аппаратных маршрутизаторов. Над 
уровнем маршрутизации располагается стек протоколов, обязательно включая 
протоколы ІР и ТСР, но также иногда и некоторые дополнительные протоколы. 
Над сетевыми протоколами располагается интерфейс сокетов, позволяющий про¬ 
граммам создавать сокеты для отдельных сетей и протоколов. Для использования 
сокетов пользовательские программы получают дескрипторы файлов. 

Над дисковыми драйверами располагаются буферный кэш и страничный кэш 
файловой системы. В ранних системах ІЖІХ буферный кэш представлял собой 
фиксированную область памяти, а остальная память использовалась для страниц 
пользователя. Во многих современных системах ІЖІХ этой фиксированной гра¬ 
ницы уже не существует, и любая страница памяти может быть схвачена для вы¬ 
полнения любой задачи, в зависимости от того, что требуется в данный момент. 

Над буферным кэшем располагаются файловые системы. Большинством сис¬ 
тем ІЖІХ поддерживаются несколько файловых систем, включая быструю фай¬ 
ловую систему Беркли, журнальную файловую систему, а также различные виды 
файловых систем Зузіет V. Все эти файловые системы совместно используют 
общий буферный кэш. Выше файловых систем помещается именование файлов, 
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управление каталогами, управление жесткими и символьными связями, а также 
другие свойства файловой системы, одинаковые для всех файловых систем. 

Над страничным кэшем располагается система виртуальной памяти. В нем вся 
логика работы со страницами, например алгоритм замещения страниц. Поверх 
него находится программа отображения файлов на виртуальную память и высо¬ 
коуровневая программа управления страничными прерываниями. Эта программа 
решает, что нужно делать при возникновении страничного прерывания. Сначала 
она проверяет допустимость обращения к памяти и, если все в порядке, определя¬ 
ет местонахождение требуемой страницы и то, как она может быть получена. 

Последний столбец имеет отношение к управлению процессами. Над диспет¬ 
чером располагается планировщик процессов, выбирающий процесс, который дол¬ 
жен быть запущен следующим. Если потоками управляет ядро, то управление 
потоками также помещается здесь, хотя в некоторых системах ІЖІХ управление 
потоками вынесено в пространство пользователя. Над планировщиком располо¬ 
жена программа для обработки сигналов и отправки их в требуемом направлении, 
а также программа, занимающаяся созданием и завершением процессов. 

Верхний уровень представляет собой интерфейс системы. Слева располагается 
интерфейс системных вызовов. Все системные вызовы поступают сюда и направ¬ 
ляются одному из модулей низших уровней в зависимости от природы системно¬ 
го вызова. Правая часть верхнего уровня представляет собой вход для аппаратных 
и эмулированных прерываний, включая сигналы, страничные прерывания, разно¬ 
образные исключительные ситуации процессора и прерывания ввода-вывода. 


Процессы в системе ІІМХ 

В предыдущих разделах мы начали наш обзор системы ІЖІХ с точки зрения пользо¬ 
вателя, сидящего за терминалом и вводящего команды с клавиатуры. Были приве¬ 
дены примеры часто использующихся команд оболочки и утилит. Этот краткий 
обзор был завершен рассмотрением структуры системы. Теперь настало время 
углубиться в ядро и более пристально рассмотреть основные концепции, поддер¬ 
живаемые системой ІЖІХ, а именно процессы, память, файловую систему и ввод- 
вывод. Эти сведения важны, так как системные вызовы — интерфейс самой опера¬ 
ционной системы — управляют ими. Например, существуют системные вызовы 
для создания процессов, доступа к памяти, открытия файлов и ввода-вывода. 

К сожалению, существует очень много версий системы ІЖІХ и между ними 
имеются определенные различия. В данной главе основное внимание будет уделе¬ 
но общим чертам всех версий, а не особенностям какой-либо одной версии. Таким 
образом, в определенных разделах (особенно в тех, где будет рассматриваться воп¬ 
рос реализации), может оказаться, что описание не соответствует в равной мере 
всем версиям. 

Основные понятия 

Единственными активными сущностями в системе ІЖІХ являются процессы. 
Процессы ІЖІХ очень похожи на классические последовательные процессы, кото¬ 
рые мы изучали в главе 2. Каждый процесс запускает одну программу и изначально 
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получает один поток управления. Другими словами, у процесса есть один счетчик 
команд, указывающий на следующую исполняемую команду процессора. Боль¬ 
шинство версий ІЖІХ позволяют процессу после того, как он запущен, создавать 
дополнительные потоки. 

ІЖІХ представляет собой многозадачную систему, так что несколько незави¬ 
симых процессов могут работать одновременно. У каждого пользователя может 
быть одновременно несколько активных процессов, так что в большой системе 
могут одновременно работать сотни и даже тысячи процессов. Действительно, на 
большинстве однопользовательских рабочих станций, даже когда пользователь 
куда-либо отлучается, работают десятки фоновых процессов, называемых демо¬ 
нами. Они запускаются автоматически при загрузке системы. 

Типичным демоном является сгоп (Іаетпоп. Он просыпается раз в минуту, про¬ 
веряя, не нужно ли чего сделать. Если у него есть работа, он ее выполняет и от¬ 
правляется спать дальше. 

Этот демон позволяет планировать в системе ІЖІХ активность на минуты, 
часы, дни и даже месяцы вперед. Например, представьте, что пользователю назна¬ 
чено явиться к зубному врачу в 3 часа дня в следующий вторник. Он может со¬ 
здать запись в базе данных демона сгоп, чтобы тот бибикнул ему, скажем, в 2:30. 
Когда наступает назначенный день, сгоп (Іаетоп видит, что у него есть работа, и за¬ 
пускает в назначенное время пищащую программу в виде нового процесса. 

Демон сгоп также используется для периодического запуска задач, например 
ежедневной архивации диска в 4 часа ночи или напоминания забывчивым пользо¬ 
вателям каждый год 31 октября купить новые страшненькие товары для веселого 
празднования Хэллоуина. Другие демоны управляют входящей и исходящей элек¬ 
тронной почтой, очередями на принтер, проверяют, достаточно ли еще осталось 
свободных страниц памяти и т. д. Демоны реализуются в системе ІЖІХ довольно 
просто, так как каждый из них представляет собой отдельный процесс, независи¬ 
мый ото всех остальных процессов. 

Процессы создаются в операционной системе ІЖІХ чрезвычайно несложно. 
Системный вызов Гогк создает точную копию исходного процесса, называемого 
родительским процессом. Новый процесс называется дочерним процессом. У ро¬ 
дительского и у дочернего процессов есть свои собственные образы памяти. Если 
родительский процесс впоследствии изменяет какие-либо свои переменные, из¬ 
менения остаются невидимыми для дочернего процесса, и наоборот. 

Открытые файлы совместно используются родительским и дочерним процес¬ 
сами. Это значит, что если какой-либо файл был открыт до выполнения системно¬ 
го вызова 'Гогк, он останется открытым в обоих процессах и в дальнейшем. Изме¬ 
нения, произведенные с этим файлом, будут видимы каждому процессу. Такое 
поведение является единственно разумным, так как эти изменения будут также 
видны любому другому процессу, который тоже откроет этот файл. 

Тот факт, что образы памяти, переменные, регистры и все остальное у родитель¬ 
ского процесса и у дочернего идентично, приводит к небольшому затруднению: 
Как процессам узнать, который из них должен исполнять родительскую програм¬ 
му, а который дочернюю? Эта проблема решается просто: системный вызов Гогк 
возвращает дочернему процессу число 0, а родительскому — отличный от нуля 
РГО (Ргосезз ГОепіШег — идентификатор процесса) дочернего процесса. Оба про¬ 
цесса могут проверить возвращаемое значение и действовать соответственно, как 
показано в листинге 10.1. 
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Листинг 10.1. Создание 

рісі = Гогк( ): 
іГ (рісі < 0) { 

/* 

ИашЛе_еггог() : 

/* 

} е1$е іГ (рісі > 0) { 

/* 

} е!$е { 

/* 


процесса в системе ШІХ 

если Гогк завершился успешно, рісі > 0 в родительском процессе */ 

Гогк потерпел неудачу (например, память или какая-либо таблица 
переполнена) */ 

здесь располагается родительская программа. */ 
здесь располагается дочерняя программа. */ 


} 


Процессы распознаются по своим РШ-идентификаторам. Как уже говорилось 
выше, при создании процесса его РГО выдается родителю нового процесса. Если 
дочерний процесс желает узнать свой РГО, он может воспользоваться системным 
вызовом деЪрісІ. Идентификаторы процессов используются различным образом. 
Например, когда дочерний процесс завершается, его РГО также выдается его 
родителю. Это может быть важно, так как у родительского процесса может быть 
много дочерних процессов. Поскольку у дочерних процессов также могут быть до¬ 
черние процессы, исходный процесс может создать целое дерево детей, внуков, 
правнуков и т. д. 

В системе ІЖІХ процессы могут общаться друг с другом с помощью разно¬ 
видности обмена сообщениями. Можно создать канал между двумя процессами, 
в который один процесс может писать поток байтов, а другой процесс может его 
читать. Эти каналы иногда называют трубами. Синхронизация процессов дости¬ 
гается путем блокирования процесса при попытке прочитать данные из пустого 
канала. Когда данные появляются в канале, процесс разблокируется. 

При помощи каналов организуются конвейеры оболочки. Когда оболочка ви¬ 
дит строку вроде 


50Гб <Г | ИеасІ 

она создает два процесса, зогі и кеасі, а также устанавливает между ними канал 
таким образом, что стандартный поток вывода программы зогі соединяется со стан¬ 
дартным потоком ввода программы кеасі. При этом все данные, формируемые про¬ 
граммой зогі, попадают напрямую программе кеасі, для чего не требуется времен¬ 
ного файла. Если канал переполняется, система приостанавливает работу программы 
зогі, пока программа кеасі не удалит из него хоть сколько-нибудь данных. 

Процессы также могут общаться другим способом: при помощи программных 
прерываний. Один процесс может послать другому так называемый сигнал. Про¬ 
цессы могут сообщить системе, какие действия следует предпринимать, когда при¬ 
дет сигнал. У процесса есть выбор: проигнорировать сигнал, перехватить его или 
позволить сигналу убить процесс (действие по умолчанию для большинства сиг¬ 
налов). Если процесс выбрал перехват посылаемых ему сигналов, он должен ука¬ 
зать процедуры обработки сигналов. Когда сигнал прибывает, управление внезап¬ 
но передается обработчику. Когда процедура обработки сигнала завершает свою 
работу, управление снова возвращается в то место процесса, в котором оно нахо¬ 
дилось, когда пришел сигнал. Обработка сигналов аналогична обработке аппарат¬ 
ных прерываний ввода-вывода. Процесс может посылать сигналы только членам 
его группы процессов, состоящей из его прямого родителя, всех прародителей, 
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братьев и сестер, а также детей (внуков и правнуков). Процесс может также по¬ 
слать сигнал сразу всей своей группе за один системный вызов. 

Сигналы используются и для других целей. Например, если процесс выполняет 
вычисления с плавающей точкой и непреднамеренно делит число на 0, он получает 
сигнал 5ІСРРЕ (Р1оаіт§-Роіпі ЕхсерНоп ЗІСпаІ — сигнал исключения при выпол¬ 
нении операции с плавающей точкой). Сигналы, требуемые стандартом Р05ІХ, 
перечислены в табл. 10.2. В большинстве систем ІЖІХ также имеются дополни¬ 
тельные сигналы, но программы, использующие их, могут оказаться непереноси¬ 
мыми на другие версии ІЖІХ. 

Таблица 10.2. Сигналы, требуемые стандартом Р05ІХ 

Сигнал Причина 

5КЗАВВТ Посылается, чтобы прервать процесс и создать дамп памяти 
ЗІСАІ-РІМ Истекло время будильника 

5ІСРРЕ Произошла ошибка при выполнении операции с плавающей точкой (например, 
деление на 0) 

5ІСНІІР Модем повесил трубку на телефонной линии, использовавшейся процессом 
5КЗІЦ- Пользователь нажал клавишу 6Е1-, чтобы прервать процесс 

ЗІСОІЛТ Пользователь нажал клавишу, требуя прекращения работы процесса с созданием 
дампа памяти 

ЗІОКІШ Посылается, чтобы уничтожить процесс (не может игнорироваться или 
перехватываться) 

ЗІСРІРЕ Процесс пишет в канал, из которого никто не читает 
ЗІСЗЕСѴ Процесс обратился к неверному адресу памяти 

ЗІСТЕВМ Вежливая просьба процессу завершить свою работу 
ЗІСІІЗВ1 Может быть определено приложением 

ЗІСІІЗВ2 Может быть определено приложением 


Системные вызовы управления процессами в ІЖІХ 

Рассмотрим теперь системные вызовы ІЖІХ, предназначенные для управления 
процессами. Основные системные вызовы перечислены в табл. 10.3. (В случае 
ошибки возвращаемое значение 5 равно -1 ,рШ означает РШ процесса, а ге$Шиа1 — 
оставшееся время до предыдущего сигнала будильника.) Обсуждение системных 
вызовов проще всего начать с системного вызова І'огк. Этот системный вызов пред¬ 
ставляет собой единственный способ создания новых процессов в системах ІЖІХ. 
Он создает точную копию оригинального процесса, включая все описатели фай¬ 
лов, регистры и все остальное. После выполнения системного вызова І'огк исход¬ 
ный процесс и его копия (родительский процесс и дочерний) идут каждый своим 
путем. Сразу после выполнения системного вызова І'огк значение всех соответству¬ 
ющих переменных в обоих процессах одинаково, но затем изменения переменных 
в одном процессе не влияет на переменные другого процесса. Системный вызов 
(Ъгк возвращает значение, равное нулю для дочернего процесса и идентификатору 
(РШ) дочернего процесса для родительского. Таким образом, два процесса могут 
определить, кто из них родитель, а кто дочерний процесс. 
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Таблица 10.3. Некоторые системные вызовы, относящиеся к процессам 

Системный вызов Описание 


ріб=1огк( ) 

ріб=ѵѵаі1рісі(рісі, &з1а11ос, оріз) 
з=ехесѵе(пате, агдѵ, епѵр) 
ехіі(зіаіиз) 

з=зідасііоп(зід, &асі, &оІсіасі) 
з=зідге1игп(&сотех!) 
з=зідргостазк(Ьоѵѵ, &зе1, &ОІ6) 
з=зідрепсііпд(зеІ) 
з=зідзизрепсі(зідтазк) 
з=кіІІ(рісі, зід) 
гезісіиаІ=аІагт(зесопсіз) 
з=раизе( ) 


Создать дочерний процесс, идентичный родительскому 
Ждать завершения дочернего процесса 
Заменить образ памяти процесса 
Завершить выполнение процесса и вернуть статус 
Определить действие, выполняемое при приходе сигнала 
Вернуть управление после обработки сигнала 
Исследовать или изменить маску сигнала 
Получить или установить блокированные сигналы 
Заменить маску сигнала и приостановить процесс 
Послать сигнал процессу 
Установить будильник 

Приостановить выполнение процесса до следующего сигнала 


В большинстве случаев после системного вызова Гогк дочернему процессу по¬ 
требуется выполнить программу, отличающуюся от программы, выполняемой ро¬ 
дительским процессом. Рассмотрим работу оболочки. Она считывает команды с 
терминала, с помощью системного вызова Гогк выполняет введенную команду, за¬ 
тем ждет окончания работы дочернего процесса, после чего считывает следующую 
команду. Для ожидания завершения дочернего процесса родительский процесс 
обращается к системному вызову иаіГрісІ. У этого системного вызова три парамет¬ 
ра. В первом параметре указывается РГО процесса, завершение которого ожидает¬ 
ся. Если вместо идентификатора процесса указать число -1, то в этом случае сис¬ 
темный вызов ожидает завершения любого дочернего процесса. Второй параметр 
представляет собой адрес переменной, в которую записывается статус завершения 
дочернего процесса (нормальное или ненормальное завершение, а также возвра¬ 
щаемое на выходе значение). Третий параметр определяет, будет ли обращающий¬ 
ся к системному вызову иаіГрісІ процесс блокирован до завершения дочернего про¬ 
цесса или сразу получит управление после обращения к системному вызову. 

В случае оболочки дочерний процесс должен выполнить команду, введенную 
пользователем. Он выполняет это при помощи системного вызова ехес, который 
заменяет весь образ памяти содержимым файла, указанным в первом параметре 
системного вызова. Крайне упрощенный вариант оболочки, иллюстрирующей ис¬ 
пользование системных вызовов Гогк, иаіГрісІ и ехес, показан в листинге 10.2. 

Листинг 10.2. Сильно упрощенная оболочка 


(ТРОЕ) { 

/* вечный цикл */ 

ІУре_рготрІ( ): 

/* вывести приглашение ко вводу */ 

геафсогтапсЦсоттапсІ. рагатз): 

/* прочитать с клавиатуры строку */ 

рісі = Гогк( ); 

/* ответвить дочерний процесс */ 

іГ (рісі < 0) { 


ргі п1:Г("Создать процесс невозможно"); 

/* ошибка */ 

сопііпие; 

/* следующий цикл */ 
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іГ (рісі != 0) { 

маіірісі (-1. йзіаГиз, 0); /* родительский процесс ждет завершения 

/* дочернего процесса */ 

} еізе { 

ехесѵе(соттапсІ, рагашз, 0); /* дочерний процесс выполняет работу */ 


} 

В самом общем случае у системного вызова ехес три параметра: имя исполняе¬ 
мого файла, указатель на массив аргументов и указатель на массив строк окруже¬ 
ния. Различные варианты этой процедуры, включая ехесі, ехесѵ, ехесіе и ехесѵе, 
позволяют опускать некоторые параметры или указывать их иными способами. 
Все эти процедуры обращаются к одному и тому же системному вызову. Хотя сам 
системный вызов называется ехес, библиотечной процедуры с таким именем нет. 
Рассмотрим случай выполнения оболочкой команды 

ср Тііеі Ше2 

используемой для копирования файла/г7 еі в файл /Ие2. После того как оболочка 
создает дочерний процесс, тот обнаруживает и исполняет файл ср и передает ему 
информацию о копируемых файлах. 

Головной модуль файла ср (как и многие другие программы) содержит опреде¬ 
ление функции 

шаігКагдс. агдѵ. епѵр) 

где аще — счетчик слов (последовательностей символов, ограниченных пробела¬ 
ми) в командной строке, включая имя программы. Для вышеприведенного приме¬ 
ра значение аще равно 3. 

Второй параметр ащѵ представляет собой указатель на массив, і- й элемент это¬ 
го массива является указателем на і-е слово командной строки. В нашем примере 
элемент ащѵ[ 0] указывает на строку «ср». Соответственно, элемент ащѵ[\] указы¬ 
вает на строку «Гііеі », а элемент агрр[ 2] указывает на строку <4і1е2>>. 

Третий параметр процедуры таіп, епѵр , представляет собой указатель на пере¬ 
менные среды и является массивом, содержащим строки вида имя = значение, ис¬ 
пользуемые для передачи программе такой информации, как тип терминала и имя 
рабочего каталога. В листинге 10.2 дочернему процессу переменные среды не пе¬ 
редаются, поэтому третий параметр епѵр в данном случае равен нулю. 

Если системный вызов ехес показался вам слишком сложным, не отчаивайтесь. 
Это самый сложный системный вызов. Все остальные значительно проще. В каче¬ 
стве примера простого системного вызова рассмотрим ехіЕ, который процессы долж¬ 
ны использовать, заканчивая исполнение. У него есть один параметр, статус вы¬ 
хода (от 0 до 255), возвращаемый родительскому процессу в переменной зіаіиз 
системного вызова каіГрісІ. Младший байт переменной зіаіиз содержит статус завер¬ 
шения, равный 0 при нормальном завершении или коду ошибки при аварийном 
завершении. Например, если родительский процесс выполняет оператор 

п = иаіГрісК-І. йзіаіиз. ОК¬ 
ОН будет приостановлен до тех пор, пока не завершится какой-либо дочерний про¬ 
цесс. Если дочерний процесс завершится со, скажем, значением статуса, равным 4, 
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в качестве параметра библиотечной процедуры ехі(, то родительский процесс 
получит РГО дочернего процесса и значение статуса, равное 0x0400 (0х означает 
в программах на языке С шестнадцатеричное число). Младший байт перемен¬ 
ной зіаіиз относится к сигналам, старший байт представляет собой значение, за¬ 
даваемое дочерним процессом в виде параметра при обращении к системному вы¬ 
зову ехіѣ. 

Если процесс уже завершил свою работу, а родительский процесс не ожидает 
этого события, то дочерний процесс переводится в так называемое состояние зом¬ 
би, то есть приостанавливается. Когда родительский процесс наконец обращается 
к библиотечной процедуре шакрій, дочерний процесс завершается. 

Несколько системных вызовов относятся к сигналам, используемым различны¬ 
ми способами. Например, если пользователь ненамеренно велит текстовому редак¬ 
тору отобразить содержание очень длинного файла, а затем осознает свою ошиб¬ 
ку, то потребуется некий способ прервать работу редактора. Обычно для этого 
пользователь нажимает специальную клавишу (например, 0Е1. или СТК1.+С), в ре¬ 
зультате чего редактору посылается сигнал. Редактор перехватывает сигнал и ос¬ 
танавливает вывод. 

Чтобы заявить о своем желании перехватить тот или иной сигнал, процесс мо¬ 
жет воспользоваться системным вызовом зідасііоп. Первый параметр этого сис¬ 
темного вызова — сигнал, который требуется перехватить (см. табл. 10.2). Второй 
параметр представляет собой указатель на структуру, в которой хранится указа¬ 
тель на процедуру обработки сигнала вместе с различными битами и флагами. 
Третий параметр указывает на структуру, в которой система возвращает инфор¬ 
мацию о текущем обрабатываемом сигнале, на случай, если позднее его нужно бу¬ 
дет восстановить. 

Обработчик сигнала может выполняться сколь угодно долго. Однако на прак¬ 
тике обработка сигналов не занимает много времени. Когда процедура обработ¬ 
ки сигнала завершает свою работу, она возвращается к той точке, в которой ее 
прервали. 

Системный вызов зідасііоп может также использоваться для игнорирования 
сигнала или чтобы восстановить действие по умолчанию, заключающееся в унич¬ 
тожении процесса. 

Нажатие на клавишу 0ЕЬ не является единственным способом послать сигнал. 
Системный вызов кі 11 позволяет процессу послать сигнал любому родственному 
процессу. Выбор названия для данного системного вызова (кШ — убить, уничто¬ 
жить) не особенно удачен, так как по большей части он используется процессами 
не для уничтожения других процессов, а, наоборот, в надежде, что этот сигнал бу¬ 
дет перехвачен и обработан соответствующим образом. 

Во многих приложениях реального времени бывает необходимо прервать про¬ 
цесс через определенный интервал времени, чтобы заставить его сделать что-либо, 
например переслать повторно возможно потерянный пакет по ненадежной линии 
связи. Для обработки данной ситуации предоставлен системный вызов аіагш 
(будильник). Параметр этого системного вызова задает временной интервал, по 
истечении которого процессу посылается сигнал 8ІСАІЛМ. У процесса в каждый 
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момент времени может быть только один будильник. Например, если процесс 
обращается к системному вызову аіагт с параметром 10 с, а 3 с спустя снова обра¬ 
щается к нему с параметром 20 с, то он получит только один сигнал через 20 с пос¬ 
ле второго системного вызова. Первый сигнал будет отменен вторым обращением 
к системному вызову аі агш. Если параметр системного вызова аі агш равен нулю, 
то такое обращение отменяет любой сигнал будильника. Если сигнал будильника 
не перехватывается, то действие по умолчанию заключается в уничтожении 
процесса. Технически возможно игнорирование данного сигнала, но смысла такое 
действие не имеет. 

Иногда случается так, что процессу нечем заняться, пока не придет сигнал. Рас¬ 
смотрим, например, обучающую программу, проверяющую скорость чтения и по¬ 
нимание текста. Она отображает на экране некоторый текст, после чего обращает¬ 
ся к системному вызову аіагт, чтобы система послала ей сигнал через 30 с. Пока 
студент читает текст, у программы нет дел. Она может сидеть в коротком цикле, 
ничего не делая, но такая реализация будет напрасно расходовать время централь¬ 
ного процессора, которое может понадобиться фоновому процессу или другому 
пользователю. Лучшее решение заключается в использовании системного вызова 
раизе, велящего операционной системе ІЖІХ приостановить работу процесса, пока 
не прибудет следующий сигнал. 

Системные вызовы управления потоками 

В первой версии системы не было потоков. Это свойство было добавлено много 
лет спустя. Изначально применялось множество различных пакетов поддержки 
потоков, однако распространение этих различных пакетов привело к тому, что на¬ 
писать переносимую программу стало очень сложно. В конце концов, системные 
вызовы, используемые для управления потоков, были стандартизированы в виде 
части стандарта Р05ІХ (РІООЗ.Іс). 

В стандарте Р05ІХ не указывается, должны ли потоки реализовываться в про¬ 
странстве ядра или в пространстве пользователя. Преимущество потоков в пользо¬ 
вательском пространстве состоит в том, что они легко реализуются беэ необходи¬ 
мости изменения ядра, а переключение потоков осуществляется очень эффективно. 
Недостаток потоков в пространстве пользователя заключается в том, что если один 
из потоков заблокируется (например, на операции ввода-вывода, семафоре или 
страничном прерывании), все потоки процесса блокируются. Ядро полагает, что 
существует только один поток, и не передает управление процессу потока, пока 
блокировка не снимется. Таким образом, системные вызовы, определенные в стан¬ 
дарте РІООЗ.Іс, были тщательно отобраны так, чтобы потоки могли быть реализова¬ 
ны любым способом. До тех пор пока пользовательские программы четко придер¬ 
живаются семантики стандарта РІООЗ.Іс, оба способа реализации должны работать 
корректно. Наиболее часто применяемые вызовы управления потоками перечис¬ 
лены в табл. 10.4. Когда используется системная реализация потоков, они явля¬ 
ются настоящими системными вызовами. При использовании потоков на уровне 
пользователя они полностью реализуются в динамической библиотеке в простран¬ 
стве пользователя. 
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Таблица 10.4. Основные вызовы управления потоками стандарта Р05ІХ 

Вызов 

Описание 

рйігеасісгеаіе 

Создать новый поток в адресном пространстве вызывающего процесса 

рЩгеасІехіІ 

Завершить вызывающий процесс 

рШгеасУоіп 

Подождать, пока не завершится процесс 

рйігеасітиіехіпіі 

Создать новый мьютекс 

рйігеасітиіехсіезігоу 

Уничтожить мьютекс 

рйігеасітиіехіоск 

Заблокировать мьютекс 

рйігеасі тиіех ипіоск 

Разблокировать мьютекс 

рШгеасІ_сопсІ_іпіІ 

Создать условную переменную 

рІЬгеасІ_сопсІ_с)е5Ігоу 

Уничтожить условную переменную 

рШгеасІ_сопсІ_ѵѵаіІ 

Ждать условную переменную 

рйігеасісопсізідпаі 

Разблокировать один поток, ждущий условную переменную 


Для действительно внимательных читателей отметим, что теперь у нас появля¬ 
ется типографская проблема. Когда управление потоками осуществляется в ядре, 
тогда такие вызовы, как «рГЬге асі сге аІе », являются системными вызовами и, сле¬ 
дуя нашим традициям, должны набираться моноширинным шрифтом: рЧігеасІ_ 
сгеаіе. Однако если это просто библиотечные процедуры в пространстве пользо¬ 
вателя, то нам следует использовать для них курсивный шрифт, как здесь: рікгеа<1_ 
сгеаіе. Для простоты мы будем везде использовать рубленый шрифт, особенно 
в следующей главе, в которой никогда точно не ясно, какие из вызовов \Уіп32 АРІ 
являются настоящими системными вызовами. Могло быть и хуже: в языке А1§о1 68 
КерогГ существовала точка, печать которой не тем шрифтом слегка меняла грам¬ 
матику языка. 

Давайте кратко рассмотрим вызовы управления потоками, показанные в табл. 10.4. 
Первый вызов рПігеасі_сгеа1:е создает новый поток. Обращение к этому системно¬ 
му вызову производится следующим образом: 

егг = рГІігеафсгеаГеШісІ. аГіг. Щпсііоп. агд): 

Этот вызов создает в текущем процессе новый поток, в котором работает про¬ 
грамма /ипсііоп, а аг& передается этой программе в качестве параметра. Идентифи¬ 
катор нового потока хранится в памяти по адресу, на который указывает первый 
параметр. С помощью параметра а((г можно задавать для нового потока опреде¬ 
ленные атрибуты, такие как приоритет планирования. После успешного выполне¬ 
ния данного системного вызова в адресном пространстве пользователя появляет¬ 
ся на один поток больше. 

Поток, выполнивший свою работу и желающий прекратить свое существова¬ 
ние, обращается к системному вызову ріЬгеасі_ехі1:. Поток может подождать, пока 
не завершится процесс, обратившись к системному вызову рѣЬгеасІ Лоі п. Если ожи¬ 
даемый поток уже завершил свою работу, системный вызов рПігеасі ^оіп выполня¬ 
ется мгновенно. В противном случае обратившийся к нему поток блокируется. 

Синхронизация потоков может осуществляться при помощи мьютексов. Как 
правило, мьютекс охраняет какой-либо ресурс, например буфер, совместно исполь¬ 
зуемый двумя потоками. Чтобы гарантировать, что только один поток в каж¬ 
дый момент времени имеет доступ к общему ресурсу, предполагается, что потоки 
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блокируют (захватывают) мьютекс перед обращением к ресурсу и разблокируют 
(отпускают) его, когда ресурс им более не нужен. До тех пор пока потоки со¬ 
блюдают данный протокол, состояния состязания можно избежать. Мьютексы по¬ 
добны двоичным семафорам, то есть семафорам, способным принимать только зна¬ 
чения 0 и 1. Название мьютекс (тиіех) образовано от английских слов шиіиаі 
ехсіизіоп — взаимное исключение. 

Мьютексы могут создаваться вызовом рѣІігеасі_ши1:ех_іпі1: и уничтожаться при 
помощи вызова рѣІігеасі_ши1:ех_сіе5І;гоу. Мьютекс может находиться в одном из двух 
состояний: блокированный и разблокированный. Поток может заблокировать 
мьютекс с помощью вызова р1:йгеаф_ти1:ех_1оск. Если мьютекс уже заблокирован, 
то поток, обратившийся к этому вызову, блокируется. Когда поток, захвативший 
мьютекс, выполнил свою работу в критической области, он должен освободить 
мьютекс, обратившись к вызову рИігеасі_ти1:ех_ип1 оск. 

Мьютексы предназначены для кратковременной блокировки, например для 
защиты совместно используемой переменной. Они не предназначаются для дол¬ 
говременной синхронизации, например для ожидания, когда освободится накопи¬ 
тель на магнитной ленте. Для долговременной синхронизации предоставляются 
переменные состояния. Эти переменные создаются с помощью вызова р1:ЬгеасІ_ 
сопсНпіІ: и уничтожаются вызовом р^йгеафсопффезЪгоу. 

Переменные состояния используются следующим образом: один поток ждет, 
когда переменная примет определенное значение, а другой поток сигнализирует 
ему изменением этой переменной. Например, обнаружив, что нужный ему нако¬ 
питель на магнитной ленте занят, поток может обратиться к вызову рЕИгеасІ_ 
сопсі (я/аіЕ, задав в качестве параметра адрес переменной, которую все потоки со¬ 
гласились связать с накопителем на магнитной ленте. Когда поток, использующий 
накопитель на магнитной ленте, наконец, освободит это устройство (возможно, 
через несколько часов), он обращается к вызову рПігеафсогкфзідпаІ, чтобы изме¬ 
нить переменную состояния и тем самым сообщить ожидающим потокам, что 
магнитофон свободен. Если ни один поток в этот момент не ждет, когда освобо¬ 
дится накопитель на магнитной ленте, этот сигнал просто теряется. Другими сло¬ 
вами, переменные состояния не считаются семафорами. С потоками, мьютексами 
и переменными состояния также определены несколько других операций. 

Реализация процессов в ІІЫІХ 

Процесс в системе ІШІХ подобен айсбергу: то, что вы видите, представляет собой 
всего лишь выступающую над водой его часть, но не менее важная часть скрыта 
под водой. У каждого процесса есть пользовательская часть, в которой работает 
программа пользователя. Однако когда один из потоков обращается к системному 
вызову, происходит эмулированное прерывание с переключением в режим ядра. 
После этого поток начинает работу в контексте ядра, с отличной картой памяти 
и полным доступом к ресурсам машины. Это все еще тот же самый поток, но 
теперь обладающий большей мощью, а также со своим стеком ядра и счетчиком 
команд в режиме ядра. Это важно, так как системный вызов может блокироваться 
на полпути, например, ожидая завершения дисковой операции. При этом счетчик 
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команд и регистры будут сохранены таким образом, чтобы позднее поток можно 
было восстановить в режиме ядра. 

Ядро поддерживает две ключевые структуры данных, относящиеся к процес¬ 
сам: таблицу процессов и структуру пользователя. Таблица процессов является 
резидентной. В ней содержится информация, необходимая для всех процессов, 
даже для тех процессов, которых в данный момент нет в памяти. Структура пользо¬ 
вателя выгружается на диск, освобождая место в памяти, когда относящийся к ней 
процесс отсутствует в памяти, чтобы не тратить память на ненужную в данный 
момент информацию. 

Информация в таблице процессов подразделяется на следующие категории: 

1. Параметры планирования. Приоритеты процессов, процессорное время, 
потребленное за последний учитываемый период, количество времени, про¬ 
веденное процессом в режиме ожидания. Вся эта информация использует¬ 
ся для выбора процесса, которому будет передано управление следующим. 

2. Образ памяти. Указатели на сегменты программы, данных и стека, или, если 
используется страничная организация памяти, указатели на соответствую¬ 
щие им таблицы страниц. Если программный сегмент используется совмест¬ 
но, то программный указатель указывает на общую таблицу программы. 
Когда процесса нет в памяти, то здесь также содержится информация о том, 
как найти части процесса на диске. 

3. Сигналы. Маски, указывающие, какие сигналы игнорируются, какие пере¬ 
хватываются, какие временно заблокированы, а какие находятся в процессе 
доставки. 

4. Разное. Текущее состояние процесса, события, ожидаемые процессом (если 
таковые есть), время до истечения интервала будильника, РГО процесса, 
РГО родительского процесса, идентификаторы пользователя и группы. 

В структуре пользователя содержится информация, которая не требуется, ког¬ 
да процесса физически нет в памяти и он не выполняется. Например, хотя процес¬ 
су, выгруженному на диск, можно послать сигнал, выгруженный процесс не мо¬ 
жет прочитать файл. По этой причине информация о сигналах должна храниться 
в таблице процессов, постоянно находящейся в памяти, даже когда процесс не при¬ 
сутствует в памяти. С другой стороны, сведения об описателях файлов могут хра¬ 
ниться в структуре пользователя и загружаться в память вместе с процессом. 

Данные, хранящиеся в структуре пользователя, включают в себя следующие 
пункты: 

1. Машинные регистры. Когда происходит прерывание с переключением в ре¬ 
жим ядра, машинные регистры (включая регистры с плавающей точкой) 
сохраняются здесь. 

2. Состояние системного вызова. Информация о текущем системном вызове, 
включая параметры и результаты. 

3. Таблица дескрипторов файлов. Когда происходит обращение к системному 
вызову, работающему с файлом, дескриптор файла используется в качестве 
индекса в данной таблице, что позволяет найти структуру данных (і-узел), 
соответствующую данному файлу. 
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4. Учетная информация. Указатель на таблицу, учитывающую процессорное 
время, использованное процессом в пользовательском и системном режи¬ 
мах. В некоторых системах здесь также ограничивается процессорное вре¬ 
мя, которое может использовать процесс, максимальный размер стека, ко¬ 
личество страниц памяти и т. д. 

5. Стек ядра. Фиксированный стек для использования процессом в режиме ядра. 

Теперь, зная, что хранится в данных таблицах, легко объяснить, как в системе 

ІЖІХ создаются процессы. Когда выполняется системный вызов Тогк, вызываю¬ 
щий процесс обращается в ядро и ищет свободную ячейку в таблице процессов, 
в которую можно записать данные о дочернем процессе. Если свободная ячейка 
находится, системный вызов копирует туда информацию из ячейки родительского 
процесса. Затем он выделяет память для сегментов данных и для стека дочернего 
процесса, куда копируются соответствующие сегменты родительского процесса. 
Структура пользователя (которая часто хранится вместе с сегментом стека) копи¬ 
руется вместе со стеком. Программный сегмент может либо копироваться, либо 
использоваться совместно, если он доступен только для чтения. Начиная с этого 
момента дочерний процесс может быть запущен. 

Когда пользователь вводит с терминала команду, например 15, оболочка созда¬ 
ет новый процесс, клонируя свой собственный процесс с помощью системного 
вызова Тогк. Новый процесс оболочки затем вызывает системный вызов ехес, что¬ 
бы считать в свою область памяти содержимое исполняемого файла Із. Эти дей¬ 
ствия показаны на рис. 10.3. 

Механизм создания нового процесса довольно прост. Для дочернего процесса 
создается новая ячейка в таблице процессов, которая заполняется по большей мере 
из соответствующей ячейки родительского процесса. Дочерний процесс получает 
РГО, затем настраивается его карта памяти. Кроме того, дочернему процессу пре¬ 
доставляется совместный доступ к файлам родительского процесса. Затем настра¬ 
иваются регистры дочернего процесса, после чего он готов к запуску. 

В принципе, следует создать полную копию адресного пространства, так как 
семантика системного вызова Іогк говорит, что никакая область памяти не ис¬ 
пользуется совместно родительским и дочерним процессами. Однако копирова¬ 
ние памяти является дорогим удовольствием, поэтому все системы ІЖІХ слегка 
жульничают. Они выделяют дочернему процессу новые таблицы страниц, но эти 
таблицы указывают на страницы родительского процесса, помеченные как доступ¬ 
ные только для чтения. Когда дочерний процесс пытается писать в такую страни¬ 
цу, происходит прерывание. При этом ядро выделяет дочернему процессу новую 
копию этой страницы, к которой этот процесс получает также и доступ записи. 
Таким образом, копируются только те страницы, в которые дочерний процесс 
пишет новые данные. Такой механизм называется копированием при записи. 
При этом сохраняется память, так как страницы с программой не копируются. 

После того как дочерний процесс начинает работу, его программа (копия обо¬ 
лочки) выполняет системный вызов ехес, задавая имя команды в качестве пара¬ 
метра. При этом ядро находит и проверяет исполняемый файл, копирует в ядро 
аргументы и строки окружения, а также освобождает старое адресное простран¬ 
ство и его таблицы страниц. 
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Выделить память для элемента 
таблицы дочернего процесса 
Заполнить элемент таблицы 
дочернего процесса из элемента 
родительского процесса 
Выделить память для стека 
и области пользователя дочернего 
процесса 

Заполнить область пользователя 
дочернего процесса из 
соответствующей области 
Выделить РЮ для дочернего процесса 
Настроить дочерний процесс на 
использование программы 
родительского процесса 
Копировать таблицы страниц для 
данных и стека 

Настроить совместное использование 
открытых файлов 

Копировать регистры родительского 
процесса в дочерний 

Рис. 10.3. Этапы выполнения команды Ів, введенной в оболочке 

После этого следует создать и заполнить новое адресное пространство. Если си¬ 
стемой поддерживается отображение файлов на адресное пространство памяти, 
как, например, в Зузіеш V, В5Б и в большинстве других версий ІЛМІХ, то таблицы 
страниц настраиваются следующим образом: в них указывается, что страниц в па¬ 
мяти нет, кроме, возможно, одной страницы со стеком, а содержимое адресного 
пространства может подгружаться из исполняемого файла на диске. Когда новый 
процесс начинает работу, он немедленно вызывает страничное прерывание, в ре¬ 
зультате которого первая страница программы подгружается с диска. Таким обра¬ 
зом, ничего не нужно загружать заранее, что позволяет быстро запускать про¬ 
граммы, а в память загружать только те страницы, которые действительно нужны 
программам. Наконец, в стек копируются аргументы и строки окружения, сигна¬ 
лы сбрасываются, а все регистры устанавливаются на ноль. С этого момента новая 
команда начинает исполнение. 

Потоки в ІШІХ 

Реализация потоков зависит от того, поддерживаются они ядром или нет. Если 
потоки ядром не поддерживаются, как, например, в 4В5Б, реализация потоков 
целиком осуществляется в библиотеке, загружающейся в пространстве пользова- 


Найти исполняемый файл 
Проверить разрешение на выполнение 
Прочитать и проверить заголовок 
Копировать аргументы, среду в ядро 
Освободить новое адресное пространство 
Копировать аргументы, среду в стек 
Сбросить сигналы 
Инициализировать регистры 
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теля. Если ядро поддерживает потоки, как в системах Зухіегп V и Зоіагіз, то у ядра 
есть чем заняться. Потоки обсуждались в общих чертах в главе 2. Здесь мы просто 
сделаем несколько замечаний по поводу реализации потоков в ядре в системе ІЛМІХ. 

Основная проблема реализации потоков заключается в поддержке корректной 
традиционной семантики ІЖІХ. Рассмотрим сначала системный вызов Іюгк. Пред¬ 
положим, что процесс с несколькими потоками (реализуемыми в ядре) выполняет 
системный вызов Іюгк. Следует ли при этом в новом процессе создать все потоки 
оригинального процесса? Предположим, что мы ответили на этот вопрос утверди¬ 
тельно. Допустим также, что один из потоков был блокирован, ожидая ввода с кла¬ 
виатуры. Должна ли в этом случае копия этого потока также быть блокирована 
ожиданием ввода с клавиатуры? Если да, то какому потоку достанется следующая, 
набранная на клавиатуре строка? Если нет, то что должен делать этот поток в но¬ 
вом процессе? Проблема касается и других аспектов. В однопоточном процессе 
такой проблемы не возникает, так как единственный поток не может быть блоки¬ 
рован при обращении к системному вызову Іюгк. Теперь рассмотрим случай, при 
котором в дочернем процессе другие потоки не создаются. Предположим, что 
один из некопируемых потоков удерживает мьютекс, который пытается получить 
единственный созданный новый поток после выполнения системного вызова 
Тогк. В этом случае мьютекс никогда не будет освобожден, и новый поток повис¬ 
нет навсегда. Существует еще множество подобных проблем. И простого решения 
у этих проблем нет. 

Файловый ввод-вывод представляет собой еще одну проблемную область. Пред¬ 
положим, что один поток блокирован при чтении из файла, а другой поток закры¬ 
вает файл и обращается к системному вызову 1 зеек, чтобы изменить текущий указа¬ 
тель файла. Что произойдет в результате этих действий? Кто знает? 

Обработка сигналов тоже представляет собой сложный вопрос. Должны ли сиг¬ 
налы направляться определенному потоку или всему процессу в целом? Вероят¬ 
но, сигнал 5ІСРРЕ (РІоаііп§-Роіп<; ЕхсерГіоп ЗІСпаІ — сигнал исключения при 
выполнении операции с плавающей точкой) должен перехватываться тем потоком, 
который его вызвал. Что следует делать, если он его не перехватывает? Следует 
ли убить этот поток? Следует ли убить все потоки процесса? Рассмотрим теперь 
сигнал 5ІСШТ, посылаемый пользователем, когда он нажимает на определенную 
клавишу. Какой поток должен перехватывать этот сигнал? Должны ли у всех по¬ 
токов быть общие маски сигналов? Любые попытки вытянуть нос в одном месте 
приводят к тому, что в каком-либо другом месте увязает хвост. Корректная реали¬ 
зация семантики потоков (не говоря уже о программе) представляет собой нетри¬ 
виальную задачу. 

Потоки в системе Ыпих 

Операционная система Ыпих поддерживает потоки в ядре довольно интересным 
способом, с которым следует познакомиться, В основе реализации системы Ыпих 
лежат идеи из системы 4.4В5Б, но в 4.4В5Б потоки на уровне ядра реализованы 
не были, так как у университета Калифорнии в Беркли кончились деньги прежде, 
чем библиотеки языка С могли быть переписаны так, чтобы решить все описан¬ 
ные выше проблемы. 
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Сердцем реализации потоков в системе Ілпих является новый системный вы¬ 
зов сіопе, отсутствующий во всех остальных версиях системы ІЖІХ. Формат об¬ 
ращения к нему выглядит следующим образом: 

рісі = с1опе(ГипсМоп. 5Іаск_рІг. зГіагі пд_Г1 ад5. агд); 

Системный вызов сіопе создает новый поток либо в текущем процессе, либо 
в новом процессе, в зависимости от флага 5кагіп§_/1а§5. Если новый поток нахо¬ 
дится в текущем процессе, он совместно использует с остальными потоками ад¬ 
ресное пространство и любое изменение каждого байта в адресном пространстве 
любым потоком тут же становится видимым всем остальным потокам процесса. 
С другой стороны, если адресное пространство не используется совместно, тогда 
новый поток получает точную копию адресного пространства, но последующие из¬ 
менения в памяти уже не видны остальным потокам. Таким образом, здесь исполь¬ 
зуется та же семантика, что и у системного вызова Гогк. 

В обоих случаях новый поток начинает выполнение функции /ипсСіоп с аргу¬ 
ментом ащ в качестве параметра. Также в обоих случаях новый поток получает 
свой собственный стек, при этом указатель стека инициализируется параметром 
Ѣіаск_ріг. 

Параметр зкагіщ_/1а§5 представляет собой битовый массив, обеспечивающий 
существенно более тонкую настройку совместного использования, нежели исполь¬ 
зуется в традиционных системах ІЖІХ. У этого флага определены пять битов, пере¬ 
численные в табл. 10.5. Каждый бит управляет одним из аспектов совместного ис¬ 
пользования, и каждый из битов может быть установлен независимо от остальных 
битов. Бит СЬОЫЕ_ѴМ определяет, будет ли виртуальная память (то есть адресное 
пространство) использоваться совместно со старыми потоками или будет копиро¬ 
ваться. Если этот бит установлен, новый поток просто помещается вместе со стары¬ 
ми потоками, так что системный вызов сіопе создает новый поток в существующем 
процессе. Если бит сброшен, новый поток получает свое собственное адресное про¬ 
странство. Это означает, что результат команды процессора 5Т0КЕ не виден осталь¬ 
ным потокам. Такое поведение подобно поведению системного вызова Гогк. Созда¬ 
ние нового адресного пространства равнозначно определению нового процесса. 

Таблица 10.5. Биты массива зНагіпдДІадз 

Флаг Значение в 1 Значение в О 

СЮЫЕ_ѴМ Создать новый поток Создать новый процесс 

СЮЫЕ_Р5 Общие рабочий каталог каталог Не использовать их совместно 

гооі и итазк 

СШЫЕ-РІІ-Е5 Общие дескрипторы файлов Копировать дескрипторы файлов 

СЮМЕ_5ІСНАЫ0 Общая таблица обработчика сигналов Копировать таблицу 
СЮМЕ_РЮ Новый поток получает старый РЮ Новый поток получает новый РЮ 


Бит СЬОЫЕ_Е5 управляет совместным использованием рабочего каталога и ка¬ 
талога гооГ, а также флага итазк. Даже если у нового потока свое собственное ад¬ 
ресное пространство, при установленном бите СЬОЫЕ_Е5 старый и новый потоки 
будут совместно использовать рабочие каталоги. Это означает, что обращение 
к системному вызову сЬсііг одним из потоков изменит рабочий каталог другого 
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потока, несмотря на то что у другого потока есть свое собственное адресное про¬ 
странство. В системе ІЖІХ обращение к системному вызову сЫіг потоком всегда 
изменяет рабочий каталог всех остальных потоков этого процесса, но никогда не 
меняет рабочих каталогов других процессов. Таким образом, этот бит обеспечива¬ 
ет разновидность совместного использования, недоступную в ІШІХ. 

Бит СЬОШ_РІЬЕ5 аналогичен биту СІОМЕЕЗ. Если он установлен, то новый 
поток пользуется теми же дескрипторами файлов, что и старые потоки. Таким об¬ 
разом, обращение к системному вызову 15еек одним потоком становится видимым 
для других потоков, что также обычно справедливо для потоков одного процесса, 
но не для потоков различных процессов. Аналогично бит СІОУЕШ/СЯДЛ© раз¬ 
решает или запрещает совместное использование таблицы обработчиков сигналов 
старым и новым потоками. Если таблица общая даже у потоков в различных 
адресных пространствах, тогда изменение обработчика в одном потоке повлияет 
и на другой поток. Наконец, бит СЮМЕ РЮ указывает, получит ли новый поток 
свой собственный РШ или будет использовать РШ своего родительского потока. 
Это свойство нужно при загрузке системы. Процессам пользователя не разреша¬ 
ется использовать этот бит. 

Такая детализация в вопросе совместного использования стала возможна бла¬ 
годаря тому, что в системе Ьіпих для различных вопросов, перечисленных в нача¬ 
ле раздела «Реализация процессов в ІШІХ» данной главы (параметры планирова¬ 
ния, образ памяти и т. д.), используются различные структуры данных. Таблица 
процессов и структура пользователя просто содержат указатели на эти структуры 
данных, поэтому легко создать новый элемент таблицы для каждого клонирован¬ 
ного потока и сделать так, чтобы он указывал либо на старую структуру, управля¬ 
ющую планированием потоков, памятью или еще чем-либо, либо на копию такой 
структуры. Сам факт наличия такой высокой степени детализации совместного 
использования еще не означает, что она полезна, особенно учитывая, что в систе¬ 
ме ІШІХ это не поддерживается. Если какая-либо программа в системе Ьіпих 
пользуется этим преимуществом, это означает, что она не может без переделок ра¬ 
ботать в системе ІШІХ. 

Планирование в системе ІЛМІХ 

Давайте теперь изучим алгоритм планирования системы ІШІХ. Поскольку ІШІХ 
всегда была многозадачной системой, ее алгоритм планирования с самого начала 
развития системы разрабатывался так, чтобы обеспечить хорошую реакцию в ин¬ 
терактивных процессах. У этого алгоритма два уровня. Низкоуровневый алгоритм 
выбирает следующий процесс из набора процессов в памяти и готовых к работе. 
Высокоуровневый алгоритм перемещает процессы из памяти на диск и обратно, что 
предоставляет всем процессам возможность попасть в память и быть запущенными. 

У каждой версии ІШІХ свой слегка отличающийся низкоуровневый алгоритм 
планирования, но у большинства этих алгоритмов есть много общих черт, кото¬ 
рые мы здесь и опишем. В низкоуровневом алгоритме используется несколько 
очередей. С каждой очередью связан диапазон непересекающихся значений прио¬ 
ритетов. Процессы, выполняющиеся в режиме пользователя (верхняя часть айс¬ 
берга), имеют положительные значения приоритетов. У процессов, выполняющих¬ 
ся в режиме ядра (обращающихся к системным вызовам), значения приоритетов 
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отрицательные. Отрицательные значения приоритетов считаются наивысшими, 
а положительные — наоборот, минимальными, как показано на рис. 10.4. В очере¬ 
дях располагаются только процессы, находящиеся в памяти и готовые к работе. 


Максимальный 

приоритет 


Ожидание дискового 
ввода-вывода 


Ожидание дискового буфера 


Ожидание 

терминального ввода 


Ожидание 

терминального вывода 


Ожидание завершения 
дочернего процесса 


Приоритет пользователя 0 


Приоритет пользователя 1 


Приоритет пользователя 2 


Приоритет пользователя 3 


Минимальный 

приоритет 


Процесс в очереди 
с уровнем приоритета 3 


Ожидающий процесс 
в режиме пользователя 


Ожидающий процесс 
в режиме ядра 


У 


Рис. 10.4. Планировщик системы ІІЬІІХ основан на структуре многоуровневой очереди 


Когда запускается (низкоуровневый) планировщик, он ищет очередь, начиная 
с самого высокого приоритета (то есть с наименьшего отрицательного значения), 
пока не находит очередь, в которой есть хотя бы один процесс. После этого в этой 
очереди выбирается и запускает первый процесс. Ему разрешается работать в те¬ 
чение некоего максимального кванта времени, как правило, 100 мс, или пока он не 
заблокируется. Если процесс использует весь свой квант времени, он помещается 
обратно, в конец очереди, а алгоритм планирования запускается снова. Таким об¬ 
разом, процессы, входящие в одну группу приоритетов, совместно используют цен¬ 
тральный процессор в порядке циклической очереди. 

Раз в секунду приоритет каждого процесса пересчитывается по формуле, со¬ 
стоящей из трех компонентов: 

ргіогііу = СР1Г_и$а§е + пісе + Ъазе. 

На основе сосчитанного нового приоритета каждый процесс прикрепляется 
к соответствующей очереди на рис. 10.4. Для получения номера очереди приори¬ 
тет, как правило, делится на некую константу. Изучим вкратце каждый из трех 
компонентов этой формулы приоритета. 
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Параметр СРѴ_иза^е (использование центрального процессора) представляет 
собой среднее значение тиков таймера в секунду, которые процесс работал в тече¬ 
ние последних нескольких секунд. При каждом тике (прерывании) таймера счет¬ 
чик использования центрального процессора в таблице процессов увеличивается 
на единицу. Этот счетчик в конце концов добавляется к приоритету процесса, 
увеличивая тем самым числовое значение его приоритета (что соответствует бо¬ 
лее низкому приоритету), в результате чего процесс попадает в менее приоритет¬ 
ную очередь. 

Однако операционная система ІЖІХ не наказывает процесс за использование 
центрального процессора навечно, и величина СРѴ_иза@е со временем уменьша¬ 
ется. В различных версиях ІЖІХ это уменьшение выполняется по-разному. Один 
из способов состоит в том, что к СРІІ_иза§е прибавляется полученное число тиков 
АТ, после чего сумма делится на два. Такой алгоритм учитывает самое последнее 
значение АТ с весовым коэффициентом 1/2, предшествующее ему — с весовым 
коэффициентом 1/4 и т. д. Алгоритм взвешивания очень быстр, так как состоит из 
всего одной операции сложения и одного сдвига, но также применяются и другие 
схемы взвешивания. 

С каждым процессом связано значение пісе. Его значение по умолчанию рав¬ 
но 0, но допустимый диапазон значений, как правило, составляет от -20 до +20. 
Процесс может установить значение пісе в диапазоне от 0 до 20 с помощью систем¬ 
ного вызова пісе 1 . Пользователь, вычисляющий в фоновом режиме число л с мил¬ 
лиардом знаков после точки, может обратиться к этому системному вызову, что¬ 
бы быть вежливым по отношению к другим пользователям. Только системный 
администратор может запросить обслуживание с более высоким приоритетом 
(то есть значения пісе от -20 до -1). О причине введения такого правила читате¬ 
лю предлагается догадаться самому. 

Когда процесс эмулирует прерывание для выполнения системного вызова в ядре, 
процесс, вероятно, должен быть блокирован, пока системный вызов не будет вы¬ 
полнен и не вернется в режим пользователя. Например, процесс может обратить¬ 
ся к системному вызову маИрісІ, ожидая, пока один из его дочерних процессов не 
закончит работу. Он может также ожидать ввода с терминала или завершения дис¬ 
ковой операции ввода-вывода и т. д. Когда процесс блокируется, он удаляется из 
структуры очереди, пока этот процесс снова не будет готов работать. 

Однако когда происходит событие, которого ждал процесс, он снова помещает¬ 
ся в очередь с отрицательным значением. Выбор очереди определяется событием, 
которого ждал процесс. На рис. 10.4 дисковый ввод-вывод показан как событие 
с наивысшим приоритетом, так что процесс, только что прочитавший или запи¬ 
савший блок диска, вероятно, получит центральный процессор в течение 100 мс. 
Отрицательные значения приоритета для дискового ввода-вывода, терминаль¬ 
ного ввода-вывода и т. д. жестко прошиты в операционной системе и могут быть 
изменены только путем перекомпиляции самой системы. Эти (отрицательные) 
значения представлены в приведенной выше формуле слагаемым Ъазе (база), и их 
величина достаточно отличается от нуля, чтобы перезапущенный процесс навер¬ 
няка попадал в другую очередь. 


1 В английском языке это слово имеет много значений. В данном случае его можно перевести, как «так¬ 
тичный», «внимательный», «любезный». — Примем, перво. 
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В основе этой схемы лежит идея как можно более быстрого удаления процес¬ 
сов из ядра. Если процесс пытается читать дисковый файл, необходимость ждать 
целую секунду между обращениями к системным вызовам геасі замедлит его работу 
во много раз. Значительно лучше позволить ему немедленно продолжить работу 
сразу после выполнения запроса, так чтобы он мог быстро обратиться к следую¬ 
щему системному вызову. Если процесс был заблокирован ожиданием ввода с тер¬ 
минала, то, очевидно, это интерактивный процесс, и ему должен быть предостав¬ 
лен наивысший приоритет, как только он перейдет в состояние готовности, чтобы 
гарантировать хорошее качество обслуживания интерактивных процессов. Таким 
образом, процессы, ограниченные производительностью процессора (то есть на¬ 
ходящиеся в положительных очередях), в основном обслуживаются после того, как 
будут обслужены все процессы, ограниченные вводом-выводом (когда все эти про¬ 
цессы окажутся заблокированы в ожидании ввода-вывода). 

Планирование в системе Ыпих 

Планирование представляет собой одну из немногих областей, в которых опера¬ 
ционная система Ыпих использует алгоритм, отличный от применяющегося в ІЖІХ. 
Мы только что рассмотрели алгоритм планирования системы ІШІХ, теперь по¬ 
знакомимся с алгоритмом планирования системы Ыпих. Начнем с того, что потоки 
в системе Ьіпих реализованы в ядре, поэтому планирование основано на потоках, 
а не на процессах. В операционной системе Ьіпих алгоритмом планирования раз¬ 
личаются три класса потоков: 

1. Потоки реального времени, обслуживаемые по алгоритму РІРО (Рігзі іп 
РігзЬ Оиі — первым прибыл — первым обслужен). 

2. Потоки реального времени, обслуживаемые в порядке циклической очереди. 

3. Потоки разделения времени 

Потоки реального времени, обслуживаемые по алгоритму РІРО, имеют наивыс¬ 
шие приоритеты и не могут прерываться другими потоками, за исключением та¬ 
кого же потока реального времени РІРО, перешедшего в состояние готовности. 
Потоки реального времени, обслуживаемые в порядке циклической очереди, пред¬ 
ставляют собой то же самое, что и потоки реального времени РІРО, но с тем отли¬ 
чием, что они могут прерываться таймером. Находящиеся в состоянии готовности 
потоки реального времени, обслуживаемые в порядке циклической очереди, вы¬ 
полняются в течение определенного кванта времени, после чего поток помещает¬ 
ся в конец своей очереди. Ни один из этих классов на самом деле не является клас¬ 
сом реального времени. Здесь нельзя задать предельный срок выполнения задания 
и предоставить гарантий его выполнения. Эти классы просто имеют более высо¬ 
кий приоритет, чем у потоков стандартного класса разделения времени. Причи¬ 
на, по которой в системе Ыпих эти классы называются классами реального вре¬ 
мени, в том, что операционная система Ыпих совместима со стандартом Р1003.4 
(расширение «реального времени» для ІЖІХ), в котором они носят эти имена. 

У каждого потока есть приоритет планирования. Значение по умолчанию рав¬ 
но 20, но оно может быть изменено при помощи системного вызова пісе(ѵаіие), 
вычитающего значение ѵаіие из 20. Поскольку ѵаіие должно находиться в диапа¬ 
зоне от -20 до +19, приоритеты всегда попадают в промежуток от 1 до 40. Цель 
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алгоритма планирования состоит в том, чтобы обеспечить грубое пропорциональ¬ 
ное соответствие качества обслуживания приоритету, то есть чем выше приори¬ 
тет, тем меньше должно быть время отклика и тем большая доля процессорного 
времени достанется процессу. 

Помимо приоритета с каждым процессом связан квант времени, то есть коли¬ 
чество тиков таймера, в течение которых процесс может выполняться. По умолча¬ 
нию системные часы тикают с частотой 100 Гц, так что каждый тик равен 10 мс. 
Этот интервал в системе Ыпих называют «джиффи» (ііГГу — мгновение, миг, мо¬ 
мент). Планировщик использует приоритет и квант следующим образом. Сначала 
он вычисляет называемую в системе Ійпих «добродетелью» (доосіпезз) величину 
каждого готового процесса по следующему алгоритму: 

іі (сіазз == геа1_1іше) доосіпезз = 1000 + ргіопіу; 

іі (сіазз == Іітезііагіпд && диапіші > 0) доосіпезз = диапіші + ргіогііу: 

іі (сіазз == Рішезііагіпд && диапіші == 0) доосіпезз = 0; 

Для обоих классов реального времени выполняется первое условие. Все, что 
дает пометка процесса, как процесса реального времени, — это гарантия, что этот 
процесс получит более высокое значение доосіпезз, чем все процессы разделения 
времени. У алгоритма есть еще одно дополнительное свойство: если у процесса, 
который запускался последним, осталось неиспользованное процессорное время, 
он получает бонус, позволяющий выиграть в спорных ситуациях. Идея состоит 
в том, что при прочих равных условиях более эффективным представляется запу¬ 
стить предыдущий процесс, так как его страницы и кэш с большой вероятностью 
еще находятся на своих местах. 

В остальном алгоритм планирования очень прост: когда нужно принять реше¬ 
ние, выбирается поток с максимальным значением «добродетели». Во время рабо¬ 
ты процесса его квант (переменная циапіит) уменьшается на единицу на каждом 
тике. Центральный процессор отнимается у потока при выполнении одного из сле¬ 
дующих условий: 

1. Квант потока уменьшился до 0. 

2. Поток блокируется на операции ввода-вывода, семафоре и т. д. 

3. В состояние готовности перешел ранее заблокированный поток с более вы¬ 
сокой «добродетелью». 

Так как кванты постоянно уменьшаются, рано или поздно у любого потока квант 
станет нулевым. Однако у потока, блокированного вводом-выводом, может остать¬ 
ся некая ненулевая величина кванта. В этот момент планировщик пересчитывает 
значения квантов для всех потоков, как готовых, так и блокированных, по следую¬ 
щей формуле: 

диапГиш = (диап1ит/2) + ргіогііу 

где квант измеряется в «джиффи», то есть в тиках. Поток, ограниченный произво¬ 
дительностью центрального процессора, как правило, быстро истратит свой квант, 
и при пересчете кванта его новое значение будет равно приоритету потока. В то же 
время у потока, ограниченного вводом-выводом, может остаться значительное ко¬ 
личество неистраченного процессорного времени, поэтому в следующий раз зна¬ 
чение его нового кванта будет больше, чем у потока, ограниченного производи- 
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тельностью процессора. Если системный вызов пісе не используется, приоритет 
потока будет равен 20 и квант станет равным 20 тикам или 200 мс. С другой сто¬ 
роны, у потока, сильно ограниченного вводом-выводом, к моменту пересчета кван¬ 
тов может остаться квант, равный 20. Поэтому если его приоритет также равен 20, 
то новое значение его кванта будет равно 20/2 + 20 = 30 тиков. Если он опять за¬ 
блокируется вводом-выводом, прежде чем успеет истратить один тик, то в следую¬ 
щий раз его квант будет равен 30/2 + 20 = 35 тиков. Эта величина стремится снизу 
к удвоенному значению приоритета. В результате применения данного алгоритма 
потоки, ограниченные вводом-выводом, получают большие кванты времени и, сле¬ 
довательно, считаются более «добродетельными», чем потоки, ограниченные про¬ 
изводительностью процессора. Таким образом, потоки, ограниченные вводом-вы¬ 
водом, получают преимущество при планировании. 

Другое свойство этого алгоритма заключается в том, что когда потоки, ограни¬ 
ченные производительностью процессора, соревнуются за право использования 
процессора, поток с большим приоритетом получает большую долю процессорно¬ 
го времени. В качестве примера рассмотрим два потока, ограниченных произво¬ 
дительностью процессора: поток А с приоритетом 20 и поток В с приоритетом 5. 
Поток А запускается первым, и через 20 тиков его квант истекает. Затем запускает¬ 
ся поток В, которому разрешается работать в течение 5 тиков. После 5 тиков, так как 
все кванты упали до нуля, они пересчитываются. Поток А снова получает 20 тиков, 
а поток В — 5 тиков. Так продолжается, пока один из потоков не выполнит всю свою 
работу, таким образом, поток А получает 80 % процессорного времени, а поток В 
получает 20 % процессорного времени. 

Загрузка ЫМХ 

Точные детали процесса загрузки операционной системы ІЖІХ варьируются от 
системы к системе. Ниже будет кратко рассмотрено, как загружается 4.4В80, но 
в своей основе это описание применимо и для других версий. Когда компьютер 
включается, в память считывается и исполняется первый сектор (главная загру¬ 
зочная запись) загружаемого диска. Этот сектор содержит небольшую (512-бай¬ 
товую) программу, загружающую автономную программу под названием ЪооС с за¬ 
грузочного устройства, как правило, с ШЕ или 5С5І-диска. Программа ЪооС сначала 
копирует саму себя в фиксированный адрес памяти в старших адресах, чтобы осво¬ 
бодить нижнюю память для операционной системы. 

Загрузившись, программа ЪооС считывает корневой каталог с загрузочного 
устройства. Чтобы сделать это, она должна понимать формат файловой систе¬ 
мы и каталога. Затем она считывает ядро операционной системы и передает ему 
управление. На этом программа ЪооС завершает свою работу, после чего уже рабо¬ 
тает ядро системы. 

Начальная программа ядра написана на ассемблере и является в значительной 
мере машинно-зависимой. Как правило, эта программа устанавливает указатель 
стека, определяет тип центрального процессора, вычисляет количество имеюще¬ 
гося в наличии ОЗУ, запрет прерываний, разрешение работы диспетчера памяти 
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и, наконец, вызывает процедуру таіп, написанную на С, чтобы запустить основ¬ 
ную часть операционной системы. 

Программа на языке С также должна проделать значительную работу по ини¬ 
циализации, но эта инициализация скорее логическая, нежели физическая. Она 
начинается с того, что выделяет память под буфер сообщений, что должно по¬ 
мочь решению проблем с загрузкой системы. По мере выполнения инициализа¬ 
ции в этот буфер записываются сообщения, информирующие о том, что происхо¬ 
дит в системе. В случае неудачной загрузки их можно выудить оттуда с помощью 
специальной программы диагностики. Этот буфер подобен черному ящику, кото¬ 
рый обычно пытаются найти на месте крушения самолета. 

Затем выделяется память для структур данных ядра. Большинство этих струк¬ 
тур имеют фиксированный размер, но размер некоторых из них, например размер 
буферного кэша и некоторых структур таблиц управления страницами памяти, 
зависит от доступного объема оперативной памяти. 

Затем операционная система начинает определение конфигурации компьюте¬ 
ра. Операционная система считывает файлы конфигурации, в которых сообщает¬ 
ся, какие типы устройств ввода-вывода могут присутствовать, и проверяет, какие 
из устройств действительно присутствуют. Если проверяемое устройство отвеча¬ 
ет, оно добавляется к таблице подключенных устройств. Если устройство не отве¬ 
чает, оно считается отсутствующим и в дальнейшем игнорируется. 

Как только список устройств определен, операционная система должна найти 
драйверы устройств. В этом месте версии ІШІХ несколько различаются между 
собой. В частности, система 4.4ВЗО не может динамически загружать драйверы 
устройств, поэтому любое устройство ввода-вывода, чей драйвер не был стати¬ 
чески скомпонован с ядром, не может использоваться. Некоторые другие версии 
ІШІХ, как, например, Ьіпих, напротив, могут динамически загружать драйверы 
(как это могут делать все версии МЗ-ЭОЗ и ^іпскиѵз). 

Аргументы в пользу динамической загрузки драйверов и против нее весьма 
интересны и их стоит кратко упомянуть. Главный аргумент в пользу динамичес¬ 
кой загрузки заключается в том, что клиентам с различными конфигурациями 
может быть поставлен один и тот же двоичный файл, который автоматически за¬ 
грузит необходимые ему драйверы, возможно даже по сети. Главный аргумент про¬ 
тив динамической загрузки состоит в том, что этот метод противоречит принци¬ 
пам безопасности системы. Если вы управляете защищенным сайтом, например 
базой данных банка или корпоративным \ѵеЬ-сервером, вероятно, вы захотите зап¬ 
ретить кому бы то ни было вставлять случайные программы в ядро операционной 
системы. Системный администратор может хранить исходные тексты операцион¬ 
ной системы и объектные файлы на защищенной машине и выполнять все работы 
по трансляции и компоновки системы на ней, после чего переносить двоичный код 
ядра на другие машины по локальной сети. Если драйверы не могут загружаться 
динамически, такой сценарий предотвращает установку в ядро не отлаженной или 
реализующей чьи-либо злые намерения программы системными операторами или 
еще кем-либо, кому известен пароль суперпользователя. Более того, в больших 
системах конфигурация аппаратуры точно известна уже во время компиляции 
и компоновки операционной системы. Изменения производятся довольно редко, 
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поэтому перекомпоновка системы при добавлении нового устройства не представ¬ 
ляет собой проблемы. 

Итак, когда загружающаяся операционная система определила конфигурацию 
аппаратного обеспечения, она должна аккуратно загрузить процесс 0, установить 
его стек и запустить этот процесс. Процесс 0 продолжает инициализацию, выпол¬ 
няя такие задачи, как программирование таймера реального времени, монтирова¬ 
ние корневой файловой системы и создание процесса 1 ( іпіі ) и страничного демо¬ 
на (процесс 2). 

Процесс іпіі проверяет свои флаги, в зависимости от которых он запускает опе¬ 
рационную систему либо в однопользовательском, либо в многопользовательском 
режиме. В первом случае он создает процесс, выполняющий оболочку, и ждет, когда 
тот завершит свою работу. Во втором случае процесс іпіі создает процесс, испол¬ 
няющий сценарий оболочки инициализации системы /еіс/гс, который может вы¬ 
полнять проверку непротиворечивости файловой системы, монтировать допол¬ 
нительные файловые системы, запускать демонов и т. д. Затем он считывает файл 
/еіс/ііуз, в котором перечисляются терминалы и некоторые их свойства. Для каж¬ 
дого разрешенного терминала он создает копию самого себя, которая затем испол¬ 
няет программу §еііу. 

Программа §е11у устанавливает для каждой линии (некоторые из них могут 
быть, например, модемами) скорость линии, после чего выводит на терминале при¬ 
глашение к входу в систему: 

Іодіп: 

После этого программа §е11у пытается прочитать имя пользователя, введенное 
с клавиатуры. Когда пользователь садится за терминал и вводит свое имя, програм¬ 
ма &еІіу завершает свою работу выполнением программы регистрации /Ып/Іофп. 
После этого программа Іо@іп запрашивает у пользователя его пароль, зашифро¬ 
вывает его и сравнивает с зашифрованным паролем, хранящимся в файле паро¬ 
лей /еіс/раввшк. Если пароль введен верно, программа Іпфг вместо себя запускает 
оболочку пользователя, которая ждет первой команды. Если пароль введен невер¬ 
но, программа Іо§іп просто еще раз спрашивает имя пользователя. Этот механизм 
проиллюстрирован на рис. 10.5 для системы с тремя терминалами. 

На рисунке процесс §е11у, работающий на терминале 0, все еще ждет ввода. 
На терминале 1 пользователь ввел имя регистрации, поэтому программа §еЫу за¬ 
пустила поверх себя процесс Іо@іп, запрашивающий пароль. На терминале 2 уже 
прошла успешная регистрация, в результате чего оболочка напечатала приглаше¬ 
ние к вводу (%). Пользователь ввел команду 

ср П Р2 

в результате которой оболочка создала дочерний процесс, исполняющий про¬ 
грамму ср. Процесс оболочки блокируется в ожидании завершения дочернего про¬ 
цесса, после чего оболочка снова напечатает приглашение к вводу и будет ждать 
ввода с клавиатуры следующей команды. Если бы пользователь на терминале 2 
вместо ср ввел сс, то запустилась бы главная программа компилятора С, который, 
в свою очередь, запустил бы несколько дочерних процессов для выполнения 
различных проходов компилятора. 
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Рис. 10.5. Последовательность исполняемых процессов при загрузке 
некоторых версий системы ІІЫІХ 


Управление памятью в ІЖІХ 

Модель памяти, используемая в системе ІЖІХ, довольно проста, что должно 
обеспечить переносимость программ, а также реализацию операционной системы 
^NIX на машинах с сильно отличающимися модулями памяти, варьирующимися 
от элементарных (например, оригинальная ІВМ РС) до сложного оборудования 
со страничной организацией. Эта область практически не изменилась за последние 
несколько десятков лет. Разработанные уже давно архитектурные решения хоро¬ 
шо себя зарекомендовали и не требуют серьезной переработки. Мы рассмотрим 
модель управления памятью в системе ІЖІХ и методы ее реализации. 

Основные понятия 

У каждого процесса в системе РШІХ есть адресное пространство, состоящее из трех 
сегментов: текста (программы), данных и стека. Пример адресного пространства 
процесса изображен на рис. 10.6, а. Текстовый (программный) сегмент содержит 
машинные команды, образующие исполняемый код программы. Он создается 
компилятором и ассемблером при трансляции программы, написанной на языке 
высокого уровня (например, С или С++) в машинный код. Как правило, тексто¬ 
вый сегмент разрешен только для чтения. Самомодифицирующиеся программы 
вышли из моды примерно в 1950 году, так как их было слишком сложно понимать 
и отлаживать. Таким образом, текстовый сегмент не изменяется ни в размерах, ни 
по своему содержанию. 




780 


Глава 10. Рассмотрение конкретных случаев: ІЛМІХ и Ыпих 


Процесс А 



Процесс В 



Указатель 

стека 


ВЗЗ 


24К 


Данные і 
Текст 


8К 

0К 


а 


б 


в 


Рис. 10.6. Виртуальное адресное пространство процесса А (а); физическая память (б); 
виртуальное адресное пространство процесса В (в) 


Сегмент данных содержит переменные, строки, массивы и другие данные про¬ 
граммы. Он состоит из двух частей: инициализированных данных и неинициали¬ 
зированных данных. По историческим причинам вторая часть называется В55 
(Виік 5Гога§е ЗузГет — запоминающее устройство большой емкости, массовое ЗУ). 
Инициализированная часть сегмента данных содержит переменные и константы 
компилятора, значения которых должны быть заданы при запуске программы. 

Например, на языке С можно объявить символьную строку и в то же время за¬ 
дать ее значение, то есть проинициализировать ее. Когда программа запускается, 
она предполагает, что в этой строке уже содержится некий осмысленный текст. 
Чтобы реализовать это, компилятор назначает строке определенное место в адрес¬ 
ном пространстве и гарантирует, что в момент запуска программы по этому адресу 
будет располагаться соответствующая строка. С точки зрения операционной сис¬ 
темы, инициализированные данные не отличаются от текста программы — и тот и 
другой сегменты содержат сформированные компилятором последовательности 
битов, загружаемые в память при запуске программы. 

Неинициализированные данные необходимы лишь с точки зрения оптимиза¬ 
ции. Когда начальное значение глобальной переменной явно не указано, то, соглас¬ 
но семантике языка С, ее значение устанавливается равным 0. На практике боль¬ 
шинство глобальных переменных не инициализируются, и, таким образом, их 
начальное значение равно 0. Это можно реализовать следующим образом: создать 
целый сегмент исполняемого двоичного файла, точно равного по размеру числу 
байтов данных, и проинициализировать весь этот сегмент нулями. 

Однако из экономии места на диске этого не делается. Файл содержит только 
те переменные, начальные значения которых явно заданы. Вместо неинициализи¬ 
рованных переменных компилятор помещает в исполняемый файл просто одно 
слово, содержащее размер области неинициализированных данных в байтах. При 
запуске программы операционная система считывает это слово, выделяет нужное 
число байтов и обнуляет их. 
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Рассмотрим это еще раз на нашем примере (см. рис. 10.6, а). Здесь текст програм¬ 
мы занимает 8 Кбайт, и инициализированные данные также занимают 8 Кбайт. 
Размер сегмента неинициализированных данных (ВЗЗ) равен 4 Кбайт. Исполняе¬ 
мый файл содержит только 16 Кбайт (текст + инициализированные данные), плюс 
короткий заголовок, в котором операционной системе указывается выделить про¬ 
грамме дополнительно 4 Кбайт после неинициализированных данных и обнулить 
их перед выполнением программы. Этот трюк позволяет сэкономить 4 Кбайт нулей 
на диске в исполняемом файле. 

В отличие от текстового сегмента, который не может изменяться, сегмент дан¬ 
ных может модифицироваться. Программы изменяют свои переменные постоян¬ 
но. Более того, многим программам требуется выделение дополнительной памяти 
динамически, во время выполнения. Чтобы реализовать это, операционная систе¬ 
ма ІІЫІХ разрешает сегменту данных расти при динамическом выделении памяти 
программам и уменьшаться при освобождении памяти программами. Програм¬ 
ма может установить размер своего сегмента данных с помощью системного вызо¬ 
ва Ьгк. Таким образом, чтобы получить больше памяти, программа может увеличить 
размер своего сегмента данных. Этим системным вызовом пользуется библиотеч¬ 
ная процедура таііос, используемая для выделения памяти. 

Третий сегмент — это сегмент стека. На большинстве компьютеров он начи¬ 
нается около старших адресов виртуального адресного пространства и растет 
вниз к 0. Если указатель стека оказывается ниже нижней границы сегмента стека, 
как правило, происходит аппаратное прерывание, при котором операционная сис¬ 
тема понижает границу сегмента стека на одну страницу памяти. Программы не 
управляют явно размером сегмента стека. 

Когда программа запускается, ее стек не пуст. Напротив, он содержит все пере¬ 
менные окружения (оболочки), а также командную строку, введенную в оболочке 
при вызове этой программы. Таким образом, программа может узнать параметры, 
с которыми она была запущена. Например, когда вводится команда 

ср 5гс сіезі 

запускается программа ср со строкой «ср зге сіезі» в стеке, что позволяет ей опре¬ 
делить имена файлов, с которыми ей предстоит работать. Строка представляется 
в виде массива указателей па отдельные аргументы командной строки, что облег¬ 
чает ее обработку. 

Когда два пользователя запускают одну и ту же программу, например тексто¬ 
вый редактор, в памяти можно хранить две копии программы редактора. Однако 
такой подход является неэффективным. Вместо этого большинством систем ІІЫІХ 
поддерживаются текстовые сегменты совместного использования. На рис. 10.6, б 
и в мы видим два процесса, А и В, совместно использующие общин текстовый сег¬ 
мент. Отображение выполняется аппаратным обеспечением виртуальной памяти. 

Сегменты данных и стека никогда не бывают общими, кроме как после выпол¬ 
нения системного вызова Іогк, и то только те страницы, которые не модифициру¬ 
ются любым из процессов. Если размер любого из сегментов должен быть увели¬ 
чен, то отсутствие свободного места в соседних страницах памяти не является 
проблемой, так как соседние виртуальные страницы памяти не обязаны отобра¬ 
жаться на соседние физические страницы. 
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На некоторых компьютерах аппаратное обеспечение поддерживает раздельные 
адресные пространства для команд и для данных. Если такая возможность есть, 
система ІЛЧІХ может ею воспользоваться. Например, на компьютере с 32-разряд- 
ными адресами при возможности использования раздельных адресных пространств 
можно получить 2 32 бит 1 адресного пространства для команд и еще 2 32 бит адрес¬ 
ного пространства для данных. Передача управления по адресу 0 будет восприни¬ 
маться как передача управления по адресу 0 в текстовом пространстве, тогда как 
при обращении к данным по адресу 0 будет использоваться адрес 0 в пространстве 
данных. Таким образом, это свойство удваивает доступное адресное пространство. 

Многими версиями ІЛЧІХ поддерживается отображение файлов на адресное 
пространство памяти. Это свойство позволяет отображать файл на часть адресно¬ 
го пространства процесса, так чтобы можно было читать из файла и писать в файл, 
как если бы это был массив, хранящийся в памяти. Отображение файла на адрес¬ 
ное пространство памяти делает произвольный доступ к нему существенно более 
легким, нежели при использовании системных вызовов, таких как геасі и мгИе. 
Совместный доступ к библиотекам предоставляется именно при помощи этого 
механизма. На рис. 10.7 показан файл, одновременно отображенный на адресные 
пространства двух процессов по различным виртуальным адресам. 


Процесс А Процесс В 



а б в 


Рис. 10.7. Два процесса совместно используют один отображенный на память файл 

Дополнительное преимущество отображения файла на память заключается 
в том, что два или более процессов могут одновременно отобразить на свое адрес¬ 
ное пространство один и тот же файл. Запись в этот файл одним из процессов 
мгновенно становится видимой всем остальным. Таким образом, отображение на 
адресное пространство памяти временного файла (который будет удален после 
завершения работы процессов) представляет собой механизм реализации общей 

1 Точнее, 2 32 байт, что равно 4 Гбайт, так как к отдельным битам процессоры, как правило, адресуются 
внутри байта или слова. — Примеч. перев. 
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памяти для нескольких процессов, причем у такого механизма будет высокая про¬ 
пускная способность. В предельном случае два или более процессов могут отобра¬ 
зить на память файл, покрывающий все адресное пространство, получая, таким 
образом, форму совместного использования памяти, что-то среднее между процес¬ 
сами и потоками. В этом случае, как и у потоков, все адресное пространство ис¬ 
пользуется совместно, но каждый процесс может управлять собственными файла¬ 
ми и сигналами, что отличает этот вариант от потоков. Однако на практике такое 
никогда не применяется. 

Системные вызовы управления памятью в ІІІЧІХ 

Стандартом Р05ІХ системные вызовы для управления памятью не определяют¬ 
ся. Эту область посчитали слишком машинно-зависимой, чтобы ее стандартизи¬ 
ровать. Вместо этого просто сделали вид, что проблемы не существует, и заявили, 
что программы, которым требуется динамическое управление памятью, могут ис¬ 
пользовать библиотечную процедуру таііос (определенную стандартом АЫЗІ С). 
Таким образом, вопрос реализации процедуры таііос был вынесен за пределы рас¬ 
смотрения стандарта Р05ІХ. В некоторых кругах такой подход был расценен как 
перекладывание бремени решения проблемы на чужие плечи. 

На практике в большинстве систем ІШІХ есть системные вызовы для управ¬ 
ления памятью. Наиболее распространенные системные вызовы перечислены 
в табл. 10.6. В случае ошибки возвращаемое значение 5 равно -1; переменные а и 
асісіг представляют собой адреса в памяти, Іеп — это длина, параметр ргоі управля¬ 
ет защитой, /Іа§з содержит различные биты ,/сі — это дескриптор файла, а о//$еі — 
смещение. Системный вызов Ьгк указывает размер сегмента данных, задавая адрес 
первого байта за его пределами. Если новое значение больше старого, сегмент дан¬ 
ных увеличивается, в противном случае он уменьшается. 


Таблица 10.6. Некоторые системные вызовы для управления памятью 


Системный вызов 

Описание 

5=Ьгк(асІсІг) 

а=ттар(асІсІг, Іеп, ргоі, Наде, М, оНзеІ) 
з=иптар(асІсІг, Іеп) 

Изменить размер сегмента данных 

Отобразить файл на память 

Отменить отображения файла на память 


Системные вызовы ігоіар и иптар управляют отображением файлов на адресное 
пространство памяти. Первый параметр системного вызова тшар, асісіг, указывает 
адрес, по которому будет отображаться файл (или его часть). Он должен быть кратен 
размеру страницы. Если этот параметр равен 0, тогда операционная система опреде¬ 
ляет этот адрес сама и возвращает его в а. Второй параметр, Іеп , задает количество 
отображаемых байтов. Он также должен быть кратен размеру страницы. Третий 
параметр, ргоі , задает режим защиты для отображаемого файла. Файл может быть 
помечен как доступный для чтения, записи, исполнения или любой комбинации 
этих трех битов. Четвертый параметр, /Іа§з, определяет, является ли отображаемый 
файл приватным или доступным для совместного использования, а также содержит 
ли параметр асісіг жесткое требование или это всего лишь намек. Пятый параметр, 
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/і 4, представляет собой дескриптор отображаемого файла. Отображаться могут 
только открытые файлы. Наконец, параметр о // зеі сообщает, с какого места дол¬ 
жен отображаться файл. Файл может быть отображен, начиная с любого байта. 

Второй системный вызов, ипшар, отменяет отображения файла на память. Если 
отменяется отображение только части файла, то остальная часть файла продолжа¬ 
ет отображаться на память. 

Реализация управления памятью в ЫNIX 

До версии ЗВ5Б большинство систем ІШІХ основывались на свопинге (подкач¬ 
ке), работавшем следующим образом. Когда загружалось больше процессов, чем 
могло поместиться в памяти, некоторые из них выгружались на диск. Выгружае¬ 
мый процесс всегда выгружался на диск целиком (исключение представляли толь¬ 
ко совместно используемые текстовые сегменты). Таким образом, процесс мог 
быть либо в памяти, либо на диске. 

Свопинг 

Перемещением данных между памятью и диском управлял верхний уровень двух¬ 
уровневого планировщика, называвшийся свопером (з\ѵаррег). Выгрузка данных 
из памяти на диск инициировалась, когда у ядра кончалась свободная память из- 
за одного из следующих событий: 

1. Системному вызову Гогк требовалась память для дочернего процесса. 

2. Системный вызов Ьгк собирался расширить сегмент данных. 

3. Разросшемуся стеку требовалась дополнительная память. 

Кроме того, когда наступало время запустить процесс, уже достаточно долго 
находящийся на диске, часто бывало необходимо удалить из памяти другой про¬ 
цесс, чтобы освободить место для запускаемого процесса. 

Выбирая жертву, свопер сначала рассматривал блокированные (например, ожи¬ 
данием ввода с терминала) процессы. Лучше удалить из памяти процесс, который 
не может работать, чем работоспособный процесс. Если такие процессы находи¬ 
лись, из них выбирался процесс с наивысшим значением суммы приоритета и вре¬ 
мени пребывания в памяти. Таким образом, хорошими кандидатами на выгрузку 
были процессы, потребившие большое количество процессорного времени, либо 
находящиеся в памяти уже достаточно долгое время, даже если большую его часть 
они занимались вводом-выводом. Если блокированных процессов не было, тогда 
на основе тех же критериев выбирался готовый процесс. 

Каждые несколько секунд свопер исследовал список выгруженных процессов, 
проверяя, не готов ли какой-либо из этих процессов к работе. Если процессы в со¬ 
стоянии готовности обнаруживались, из них выбирался процесс, дольше всех нахо¬ 
дящийся на диске. Затем свопер проверял, будет ли это легкий свопинг или тяже¬ 
лый. Легким свопингом считался тот, для которого не требовалось дополнительное 
высвобождение памяти. При этом нужно было всего лишь загрузить выгружен¬ 
ный на диск процесс. Тяжелым свопингом назывался свопинг, при котором для 
загрузки в память выгруженного на диск процесса из нее требовалось удалить один 
или несколько других процессов. 
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Затем весь этот алгоритм повторялся до тех пор, пока не выполнялось одно из 
следующих двух условий: (1) на диске не оставалось процессов, готовых к работе, 
или (2) в памяти не оставалось места для новых процессов. Чтобы не терять боль¬ 
шую часть производительности системы на свопинг, ни один процесс не выгру¬ 
жался на диск, если он пробыл в памяти менее 2 с. 

Свободное место в памяти и на устройстве перекачки учитывалось при помо¬ 
щи связного списка свободных пространств. Когда требовалось свободное про¬ 
странство в памяти или на диске, из списка выбиралось первое подходящее сво¬ 
бодное пространство. После этого в список возвращался остаток от свободного 
пространства. 

Постраничная подкачка в системе ІІЫІХ 

Все версии операционной системы ІШІХ для компьютеров РБР-11 и Іпіегсіаіа, 
а также начальная версия для машины ѴАХ были основаны на свопинге, о котором 
только что рассказывалось. Однако, начиная с версии ЗВ5Б, университет в Берк¬ 
ли добавил к системе страничную подкачку, чтобы предоставить возможность 
работать с программами самых больших размеров. Практически во всех версиях 
системы ІШІХ теперь есть страничная подкачка по требованию, появившаяся 
впервые в версии ЗВ5Б. Ниже мы опишем строение версии 4В5Б, но Зузіет V 
основана на 4В5Б и во многом схожа с нею. 

Идея, лежащая в основе страничной подкачки в системе 4В5Б, проста: чтобы 
работать, процессу не нужно целиком находиться в памяти. Все, что в действи¬ 
тельности требуется, — это структура пользователя и таблицы страниц. Если они 
загружены, то процесс считается находящимся в памяти и может быть запущен 
планировщиком. Страницы с сегментами текста, данных и стека загружаются в па¬ 
мять динамически, по мере обращения к ним. Если пользовательской структуры 
и таблицы страниц нет в памяти, то процесс не может быть запущен, пока свопер 
не загрузит их. 

В системе Вегкеіеу ІШІХ не используется модель рабочего набора или любая 
другая форма опережающей подкачки страниц, так как для этого требуется знать, 
какие страницы используются в данный момент, а какие нет. Поскольку в машине 
ѴАХ не было битов обращений к памяти, эту информацию было получить непро¬ 
сто (хотя это можно было поддержать программно за счет значительных дополни¬ 
тельных накладных расходов). 

Страничная подкачка реализуется частично ядром и частично новым про¬ 
цессом, называемым страничным демоном. Страничный демон — это процесс 2 
(процесс 0 — это свопер, а процесс 1 — іпіі, как показано на рис. 10.5). Как и все 
демоны, страничный демон периодически запускается и смотрит, есть ли для него 
работа. Если он обнаруживает, что количество страниц в списке свободных стра¬ 
ниц слишком мало, страничный демон инициирует действия по освобождению 
дополнительных страниц. 

Организация памяти в 4В5Б показана на рис. 10.8. Память делится натри части. 
Первые две части, ядро операционной системы и карта памяти, фиксированы в фи¬ 
зической памяти (то есть никогда не выгружаются). Остальная память компьютера 
делится на страничные блоки, каждый из которых может содержать страницу 
текста, данных или стека или находиться в списке свободных страниц. 
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Карта памяти содержит информацию о содержимом страничных блоков. Для 
каждого страничного блока в карте памяти есть запись фиксированной длины. При 
килобайтных страничных блоках и 16-байтовых записях карты памяти на карту 
памяти расходуется менее 2 % от общего объема памяти. Первые два поля записи 
карты памяти используются только тогда, когда соответствующий страничный 
блок находится в списке свободных страниц. В этом случае они сшивают свобод¬ 
ные страницы в двусвязный список. Следующие три записи используются, когда 
страничный блок содержит информацию. У каждой страницы в памяти есть фик¬ 
сированное место хранения на диске, в которое она помещается, когда выгружает¬ 
ся из памяти. Еще три поля содержат ссылку на запись в таблице процессов, тип 
хранящегося в странице сегмента и смещение в сегменте процесса. Последнее поле 
содержит некоторые флаги, нужные для алгоритма страничной подкачки. 


Оперативная память 


Часы с двумя 
стрелками 
сканируют 
карту памяти 




Страничный 

блокЗ 


Страничный 
блок 2 


Страничный 
блок 1 


Страничный 
блок О 


Ядро 4.3 
В50 


Запись карты памяти 


Индекс следующей записи 


Индекс предыдущей записи 


Номер блока диска 


Номер блока устройства 


Хэш-код блока 


Индекс предыдущей записи 


Текст/данные/стек 


Смещение в сегменте 


Используются, 

> когда страничный 
| блок находится 
в свободном списке 


Записи карты 
памяти, по одной 
на страничный блок 


/ 

Свободен 


\ 

Требуется 


Бит фиксации 
в памяти 


В процессе 
переноса 


Рис. 10.8. Карта памяти в 4В5Р 


При запуске процесс может вызвать страничное прерывание, если одной или 
нескольких его страниц не окажется в памяти. При страничном прерывании опе¬ 
рационная система берет первый страничный блок из списка свободных страниц, 
удаляет его из списка и считывает в него требуемую страницу. Если список сво¬ 
бодных страниц пуст, выполнение процесса приостанавливается до тех пор, пока 
страничный демон не освободит страничный блок. 


Алгоритм замещения страниц 

Алгоритм замещения страниц выполняется страничным демоном. Раз в 250 мс он 
просыпается, чтобы сравнить количество свободных страничных блоков с систем¬ 
ным параметром Іоіз/гее (равным, как правило, 1/4 объема памяти). Если число 
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свободных страничных блоков меньше, чем значение этого параметра, страничный 
демон начинает переносить страницы из памяти на диск, пока количество свобод¬ 
ных страничных блоков не станет равно Іоіз/гее. Если же количество свободных 
страничных блоков больше или равно Іоіз/гее, тогда страничный демон, ничего 
не предпринимая, отправляется спать дальше. Если у компьютера много памяти 
и мало активных процессов, страничный демон спит практически все время. 

Страничный демон использует модифицированную версию алгоритма часов. 
Это глобальный алгоритм, то есть при удалении страницы он не учитывает, чья 
зто страница. Таким образом, количество страниц, выделяемых каждому процес¬ 
су, меняется со временем. 

Основной алгоритм часов работает, сканируя в цикле страничные блоки (как 
если бы они лежали на окружности циферблата часов). На первом проходе, когда 
стрелка часов указывает на страничный блок, сбрасывается его бит использова¬ 
ния. На втором проходе у каждого страничного блока, к которому не было доступа 
с момента первого прохода, бит использования останется сброшенным, и этот стра¬ 
ничный блок будет помещен в список свободных страниц (после записи его на 
диск, если он «грязный»). Страничный блок в списке свободных страниц сохра¬ 
няет свое содержание, что позволяет восстановить страницу, если она потребует¬ 
ся прежде, чем будет перезаписана. 

На машинах типа VАХ, у которых не было битов использования, когда стрелка 
часов указывала на страничный блок на первом проходе, сбрасывался программ¬ 
ный бит, а страница помечалась в таблице страниц как недействительная. При сле¬ 
дующем доступе к странице происходило страничное прерывание, что позволяло 
операционной системе установить программный бит использования. Эффект дос¬ 
тигался тот же самый, что и при использовании аппаратного бита использования, 
но реализация была значительно более сложной и медленной. Таким образом, про¬ 
граммное обеспечение расплачивалось за недостаточно развитую схему аппарат¬ 
ного обеспечения. 

Изначально в ВегЫеу ІШІХ использовался основной алгоритм часов, но затем 
было обнаружено, что при больших объемах оперативной памяти проходы за¬ 
нимают слишком много времени. Тогда алгоритм был заменен алгоритмом часов 
с двумя стрелками (см. рис. 10.8). В этом алгоритме страничный демон под¬ 
держивает два указателя на карту памяти. При работе он сначала очищает бит 
использования передней стрелкой, а затем проверяет этот бит задней стрелкой. 
После чего перемещает обе стрелки. Если две стрелки находятся близко друг от 
друга, то только у очень активно используемых страниц появляется шанс, что к 
ним будет обращение между проходами двух стрелок. Если же стрелки разнесены 
на 359 градусов (то есть задняя стрелка находится слегка впереди передней), мы 
снова получаем исходный алгоритм часов. При каждом запуске страничного 
демона стрелки проходят не полный оборот, а столько, сколько необходимо, что¬ 
бы количество страниц в списке свободных страниц было не менее Іоіз/гее. 

Если операционная система обнаруживает, что частота подкачки страниц 
слишком высока, а количество свободных страниц все время ниже Ыз/гее, свопер 
начинает удалять из памяти один или несколько процессов, чтобы остановить 
состязание за свободные страничные блоки. Алгоритм свопинга в системе 4В5Э 
следующий. Сначала свопер проверяет, есть ли процесс, который бездействовал 
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в течение 20 и более секунд. Если такие процессы есть, из них выбирается бездей¬ 
ствовавший в течение максимального срока и выгружается на диск. Если таких 
процессов нет, изучаются четыре самых больших процесса, из которых выбирает¬ 
ся тот, который находился в памяти дольше всех, и выгружается на диск. При не¬ 
обходимости этот алгоритм повторяется до тех пор, пока не будет высвобождено 
достаточное количество памяти. 

Каждые несколько секунд свопер проверяет, есть ли на диске готовые процес¬ 
сы, которые следует загрузить в память. Каждому процессу на диске присваива¬ 
ется значение, зависящее от времени его пребывания в выгруженном состоянии, 
размера, значения, использовавшегося при обращении к системному вызову пісе 
(если такое обращение было), и от того, как долго этот процесс спал, прежде чем 
был выгружен на диск. Эта функция обычно взвешивается так, чтобы загружать 
в память процесс, дольше всех находящийся в выгруженном состоянии, если толь¬ 
ко он не крайне большой. Теория утверждает, что загружать большие процессы 
дорого, поэтому их не следует перемещать туда-сюда слишком часто. Загрузка про¬ 
цесса производится только при условии наличия достаточного количества свобод¬ 
ных страниц, чтобы, когда случится неизбежное страничное прерывание, для него 
нашлись свободные страничные блоки. Свопер загружает в память только струк¬ 
туру пользователя и таблицы страниц. Страницы с текстом, данными и стеком 
подгружаются при помощи обычной страничной подкачки. 

У каждого сегмента каждого активного процесса есть место на диске, где он 
располагается, когда его страницы удаляются из памяти. Сегменты данных и сте¬ 
ка сохраняются на временном устройстве, но текст программы подгружается из 
самого исполняемого двоичного файла. Для текста программы временная копия 
не используется. 

Страничная подкачка в ЗузСет V во многом схожа с применяемой в системе 
4В5Э, что не удивительно, так как версия ІЖІХ университета в Беркли уже в те¬ 
чение многих лет стабильно работала, прежде чем страничная подкачка была до¬ 
бавлена к Зузіет V. Тем не менее между этими версиями операционной системы 
есть два интересных различия. 

Во-первых, в ЗузСеш V вместо алгоритма часов с двумя стрелками использует¬ 
ся оригинальный алгоритм часов с одной стрелкой. Более того, вместо того чтобы 
помещать страницу в список свободных страниц на втором проходе, страница по¬ 
мещается туда только в случае, если она не использовалась в течение нескольких 
последовательных проходов. Хотя при таком решении страницы не освобождаются 
так быстро, как это делается алгоритмом в Вегкеіеу ІЖІХ, оно значительно увели¬ 
чивает вероятность того, что освобожденная страница не потребуется тут же снова. 

Во-вторых, вместо единственной переменной Іоіз/геев Зузіет V используются 
две переменные, тіп и тах. Когда количество свободных страниц опускается ниже 
тіп, страничный демон начинает освобождать страницы. Демон продолжает рабо¬ 
тать до тех пор, пока число свободных страниц не сравняется со значением тах. 
Такой подход позволяет избежать неустойчивости, возможной в системе 405Э. 
Рассмотрим ситуацию, в которой количество свободных страниц на единицу мень¬ 
ше, чем Іоіз/гее, поэтому страничный демон освобождает одну страницу, чтобы 
привести количество свободных страниц в соответствие со значением Іоіз/гее. Затем 
происходит еще одно страничное прерывание, и количество свободных страниц 




Управление памятью в І1ЫІХ 


789 


опять становится на единицу меньше Іоіз/гее, в результате страничный демон сно¬ 
ва начинает работать. Если установить значение тіп существенно большим, чем 
тіп, страничный демон, завершив освобождение страниц, создает достаточный за¬ 
пас, чтобы иметь возможность отдохнуть некоторое время. 

Управление памятью в 1_іпих 

Каждый процесс системы Еіпих на 32-разрядной машине получает 3 Гбайт вирту¬ 
ального адресного пространства для себя, с оставшимся 1 Гбайт памяти для стра¬ 
ничных таблиц и других данных ядра. Один гигабайт ядра не виден в пользова¬ 
тельском режиме, но становится доступным, когда процесс переключается в режим 
ядра. Адресное пространство создается при создании процесса и перезаписывает¬ 
ся системным вызовом ехес. 

Виртуальное адресное пространство делится на однородные непрерывные об¬ 
ласти, выровненные по границам страниц. Таким образом, каждая область состо¬ 
ит из набора соседних страниц с одинаковым режимом защиты и одинаковыми 
свойствами подкачки. Примерами областей являются текстовый сегмент и файлы, 
отображенные на память (см. рис. 10.7). Между областями в виртуальном адрес¬ 
ном пространстве могут быть свободные участки. Любое обращение процесса к 
памяти в этих свободных участках приводит к фатальному страничному прерыва¬ 
нию. Размер страницы фиксирован, например 4 Кбайт для процессора Репііиш 
и 8 Кбайт для процессора АІрЬа. 

Каждая область описывается в ядре записью ѵт_агеа_зІгисІ. Все структуры 
ѵт_агеа_зігисі одного процесса связаны вместе в список, отсортированный по вир¬ 
туальным адресам, что позволяет быстро находить все страницы. Когда список ста¬ 
новится слишком длинным (более 32 записей), создается дерево для ускорения 
поиска. Запись ѵт_агеа_зІгисі перечисляет свойства области. К ним относятся ре¬ 
жим защиты (например, только чтение или чтение/запись), является ли данная 
область фиксированной в памяти (невыгружаемой), и направление, в котором 
область может расти (вверх для сегментов данных, вниз для сегмента стека). 

Структура ѵт_агеа_5Ігис( также содержит данные о том, является ли данная 
область приватной областью процесса или ее совместно используют несколько 
процессов. После системного вызова Гогк система Еіпих создает копию списка об¬ 
ластей для дочернего процесса, но у дочернего и родительского процессов оказы¬ 
ваются указатели на одни и те же таблицы страниц. Области помечаются как дос¬ 
тупные для чтения/записи, но страницы доступны только для чтения. Если любой 
из процессов пытается записать данные в такую страницу, происходит прерывание, 
ядро видит, что область логически доступна для записи, а страница недоступна, по¬ 
этому оно дает процессу копию страницы, которую помечает как доступную для 
чтения/записи. Таким образом реализован механизм копирования при записи. 

Кроме того, в структуре ѵт_агеа_зСтс( записано, есть ли у этой области памя¬ 
ти место хранения на диске, и если да, то где оно расположено. Текстовые сегмен¬ 
ты в качестве резервного хранения используют двоичные файлы, а отображаемые 
на адресное пространство памяти файлы выгружаются на диск в соответствующие 
им файлы. Всем остальным областям, таким как область стека, не назначаются 
области резервного хранения, пока не потребуется их выгрузка на диск. 
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В системе Ыпих используется трехуровневая схема страничной подкачки. Хотя 
эта схема была реализована в системе для процессора АІрЬа, она также использу¬ 
ется (в упрощенном виде) для всех архитектур. Каждый виртуальный адрес раз¬ 
бивается на четыре поля, как показано на рис. 10.9. Каталоговое поле использует¬ 
ся как индекс в глобальном каталоге, в котором есть личный каталог для каждого 
процесса. Содержание элемента каталога является указателем на одну из средних 
страничных таблиц, которые тоже проиндексированы полем виртуального адреса. 
Наконец, элемент средней таблицы указывает на таблицу страниц, также проин¬ 
дексированную полем страницы виртуального адреса. Элемент в последней таб¬ 
лице содержит указатель на нужную страницу. На компьютерах с процессором 
Реп (лит используется только двухуровневая организация страниц. В этом случае 
каждый средний страничный каталог содержит только одну запись. Таким обра¬ 
зом, глобальный каталог фактически указывает на таблицу страниц. 


Страница 



Рис. 10.9. В І_іпих используются трехуровневые таблицы страниц 


Физическая память используется для различных целей. Само ядро жестко фик¬ 
сировано. Ни одна его часть не выгружается на диск. Остальная часть памяти дос¬ 
тупна для страниц пользователей, буферного кэша, используемого файловой сис¬ 
темой, страничного кэша и других задач. Буферный кэш содержит блоки файлов, 
которые были недавно считаны или были считаны заранее в надежде на то, что они 
скоро могут понадобиться. Его размер динамически меняется. Буферный кэш со¬ 
стязается за место в памяти со страницами пользователей. Страничный кэш в дей¬ 
ствительности не является настоящим отдельным кэшем, а представляет собой 
просто набор страниц пользователя, которые более не нужны и ожидают выгруз¬ 
ки на диск. Если страница, находящаяся в страничном кэше, потребуется снова, 
прежде чем она будет удалена из памяти, ее можно быстро объявить находящейся 
в памяти. 

Кроме этого, операционная система Біпих поддерживает динамически загру¬ 
жаемые модули, в основном драйверы устройств. Они могут быть произвольного 
размера и каждому из них должен быть выделен непрерывный участок в памяти 
ядра. Для выполнения всех этих требований система Біпих управляет памятью 
таким образом, что она может получить по желанию участок памяти произволь¬ 
ного размера. Для этого используется алгоритм, известный как «дружественный» 
алгоритм. Он будет описан ниже. 
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Основная идея управления блоками памяти заключается в следующем. Из¬ 
начально память состоит из единого непрерывного участка. В нашем примере на 
рис. 10.10, а размер этого участка равен 64 страницам. Когда поступает запрос на 
выделение памяти, он сначала округляется до степени двух, например до 8 стра¬ 
ниц. Затем весь блок памяти делится пополам (рис. 10.10, б). Так как получивши¬ 
еся в результате этого деления надвое участки памяти все еще слишком велики, 
нижняя половина делится пополам еще (рис. 10.10, в) и еще (рис. 10.10, г). Теперь 
мы получили участок памяти нужного размера. Этот участок предоставляется об¬ 
ратившемуся процессу (затененный на рис. 10.10, г). 


64 


32 


32 


32 


32 


32 


32 


32 


32 




16 


16 


іб 


8 


8 


8 


8 



32 





8 


4 

4 


4 

4 


4 

- 4 




16 


8 


8 


8 


8 


8 


8 






8 


8 


8 


8 


8 


8 

а 

б 

в 

а 

а 

е 

Ж 

3 

и 


Рис. 10.10. Этапы работы дружественного алгоритма 

Теперь предположим, что приходит второй запрос на 8 страниц. Он может быть 
удовлетворен немедленно (рис. 10.10, д ). Следом поступает запрос на 4 страницы. 
При этом делится надвое наименьший участок (рис. 10.10, ё) и выделяется полови¬ 
на от половины (рис. 10.10, ж). Затем освобождается второй 8-страничный участок 
(рис. 10.10, з ). Наконец, освобождается оставшийся 8-страничный участок. Посколь¬ 
ку эти два участка были «приятелями», то есть они вышли из одного 16-странич¬ 
ного блока, они снова объединяются в 16-страничный блок (рис. 10.10, и). 

Операционная система Ьіпих управляет памятью при помощи данного алго¬ 
ритма. К нему добавляется массив, в котором первый элемент представляет собой 
начало списка блоков размером в 1 единицу, второй элемент является началом 
списка блоков размером в 2 единицы, третий элемент — началом списка блоков 
размером в 4 единицы и т. д. Таким образом, можно быстро найти любой блок 
с размером кратным степени 2. 

Этот алгоритм приводит к существенной внутренней фрагментации, так как, 
если вам нужен 65-страничный участок, вы получите 128-страничный блок. 

Чтобы как-то решить эту проблему, в системе Ьіпих есть второй алгоритм 
выделения памяти, выбирающий блоки памяти при помощи «приятельского» 
алгоритма, а затем нарезающий из этих блоков более мелкие фрагменты и управ¬ 
ляющий этими фрагментами отдельно. Кроме того, существует третий алгоритм 
выделения памяти, использующийся, когда выделяемая память должна быть 
непрерывна только в виртуальном адресном пространстве, но не в физической 
памяти. Все эти алгоритмы выделения памяти были взяты из системы Зувіет V. 
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Операционная система Ілпих является системой, предоставляющей страницы 
по требованию, без предварительной загрузки страниц и без концепции рабочего 
набора (хотя в ней есть системный вызов для указания пользователем страницы, 
которая ему может скоро понадобиться). Текстовые сегменты и отображаемые на 
адресное пространство памяти файлы подгружаются из соответствующих им фай¬ 
лов на диске. Все остальное выгружается либо в область подкачки, если она при¬ 
сутствует, либо в файлы подкачки фиксированной длины, которых может быть от 
одного до восьми. Файлы подкачки могут динамически добавляться и удаляться, 
и у каждого есть свой приоритет. Выгрузка страниц в отдельный раздел диска, до¬ 
ступ к которому осуществляется как к отдельному устройству, не содержащему 
файловой системы, более эффективна, чем выгрузка в файл, по нескольким при¬ 
чинам. Во-первых, не требуется преобразование блоков файла в блоки диска. Во- 
вторых, физическая запись может быть любого размера, а не только размера блока 
файла. В-третьих, страница всегда пишется прямо на устройство в виде единого не¬ 
прерывного участка, а при записи в файл подкачки это может быть и не всегда так. 

Страницы на устройстве подкачки или дисковом разделе подкачки не выделя¬ 
ются, пока они не потребуются. Каждое устройство или файл подкачки начинается 
с битового массива, в котором сообщается, какие страницы свободны. Когда страни¬ 
ца, у которой нет места хранения на диске, должна быть удалена из памяти, из фай¬ 
лов (или разделов) подкачки, в которых еще есть свободное место, выбирается файл 
с наивысшим приоритетом, и в нем выделяется место для страницы. Как правило, 
у раздела подкачки (если таковой имеется) более высокий приоритет, чем у любого 
файла подкачки. Координата страницы на диске записывается в таблицу страниц. 

Алгоритм замещения страниц работает следующим образом. Система Ілпих 
пытается поддерживать некоторые страницы свободными, чтобы их можно было 
предоставить при необходимости. Конечно, этот пул страниц должен постоянно 
пополняться, поэтому реальный алгоритм страничной подкачки заключается в том, 
как это происходит. Во время загрузки процесс іпіі запускает страничный демон 
кзшарсі, который работает раз в секунду. Он проверяет, есть ли достаточное коли¬ 
чество свободных страниц. Если да, он отправляется спать еще секунду, хотя он 
может быть разбужен и раньше, если внезапно понадобятся дополнительные стра¬ 
ницы. Страничный демон состоит из цикла, который выполняется до шести раз 
с возрастающей срочностью. Почему шесть? Вероятно, автор программы думал, 
что четырех будет недостаточно, а восемь будет слишком много. В отдельных мес¬ 
тах операционная система Ілпих реализована именно так. 

Тело цикла выполняет обращения к трем процедурам, каждая из которых пы¬ 
тается получить различные типы страниц. Значение срочности передается в виде 
параметра, сообщающего процедуре, сколько усилий требуется предпринять, что¬ 
бы получить некоторые страницы. Как правило, это означает, сколько страниц 
нужно проверить, прежде чем опустить руки. В результате этот алгоритм сначала 
выбирает легко доступные страницы каждой категории, после чего переходит к 
труднодоступным. Когда получено достаточное количество страниц, страничный 
демон снова отправляется спать. 

Первая процедура пытается получить те страницы из страничного кэша и буфер¬ 
ного кэша файловой системы, к которым в последнее время не было обращений, 
для чего используется алгоритм часов. Вторая процедура ищет совместно исполь- 
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зуемые страницы, которыми никто из пользователей, похоже, не пользуется актив¬ 
но. Третья процедура, пытающаяся получить страницы, используемые одиночными 
пользователями, является наиболее интересной, поэтому рассмотрим ее подробнее. 

Сначала выполняется цикл по всем процессам, в котором определяется, у какого 
процесса больше всего страниц на данный момент находится в памяти. Как только 
такой процесс найден, сканируются все его структуры ѵт_агеа_5ІгисІ и изучаются 
все страницы в порядке виртуальных адресов, начиная с того места, на котором 
этот процесс был отложен в прошлый раз. Если страница недействительна, отсут¬ 
ствует в памяти, используется совместно, фиксирована в памяти или использует¬ 
ся для ОМА, то она пропускается. Если у страницы установлен бит обращения к 
ней, этот бит сбрасывается и страница отправляется в резерв. Если же бит сбро¬ 
шен, эта страница отнимается у процесса. В результате данный алгоритм подобен 
алгоритму часов (с той разницей, что страницы не сканируются в порядке ЕІЕО). 

Если страница, выбранная для удаления из памяти, чистая, она удаляется не¬ 
медленно. Если страница «грязная» и у нее есть место резервного хранения на 
диске, она устанавливается в очередь записи на диск. Наконец, если у «грязной» 
страницы нет места резервного хранения на диске, она отправляется в странич¬ 
ный кэш, из которого она может быть снова получена позднее, если обращение к 
ней поступит прежде, чем она будет фактически выгружена на диск. В основе идеи 
сканирования страниц в порядке виртуальных адресов лежит надежда на то, что 
страницы, расположенные близко друг к другу в виртуальном адресном простран¬ 
стве, скорее всего будут использоваться или не использоваться вместе, как единая 
группа, поэтому их следует записывать на диск как группу, а затем вместе считы¬ 
вать в память. 

В управлении памятью принимает участие еще один демон, Ъсі/Іизк. Он перио¬ 
дически просыпается (а в некоторых случаях его явно будят), чтобы проверить, не 
превысило ли количество «грязных» страниц определенного предельного уровня. 
Если превысило, демон начинает сохранять их на диске. 


Ввод-вывод в системе ІІЫІХ 

Система ввода-вывода в ІШІХ довольно проста. Как правило, все устройства вво¬ 
да-вывода выглядят как файлы, и доступ к ним осуществляется с помощью тех же 
системных вызовов геасі и мгіѣе, которые используются для доступа к обычным 
файлам. В некоторых случаях должны быть заданы параметры устройства, для чего 
служит специальный системный вызов. В следующих разделах мы рассмотрим эти 
вопросы. 

Основные понятия 

Как и у всех компьютеров, у машин, работающих под управлением операционной 
системы ІШІХ, есть устройства ввода-вывода, такие как диски, принтеры и сети, 
соединенные с ними. Требуется некий способ предоставления программам доступа 
к этим устройствам. Хотя возможны различные варианты решений данного вопро¬ 
са, подход, применяемый в операционной системе ІЖІХ, заключается в интегри- 
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ровании всех устройств в файловую систему в виде так называемых специальных 
файлов. Каждому устройству ввода-вывода назначается имя пути, обычно в ката¬ 
логе /<1еѵ. Например, диск может иметь путь /Неѵ/Ыі, у принтера может быть путь 
/сіеѵ/ір, а у сети — /йеѵ/пеі. 

Доступ к этим специальным файлам осуществляется так же, как и к обычным 
файлам. Для этого не требуется никаких специальных команд или системных вызо¬ 
вов. Вполне подойдут обычные системные вызовы геасі и игііе. Например, команда 

ср Гііе /сіеѵ/1 р 

скопирует файл /Не на принтер, в результате чего этот файл будет распечатан (при 
условии, что у пользователя есть разрешение доступа к /Неѵ/Ір). Программы мо¬ 
гут открывать, читать специальные файлы, а также писать в них тем же способом, 
что и в обычные файлы. На самом деле программа ср в приведенном выше приме¬ 
ре даже не знает, что она занимается печатью файла на принтере. Таким образом, 
для выполнения ввода-вывода не требуется специального механизма. 

Специальные файлы подразделяются на две категории: блочные и символьные. 
Блочный специальный файл — это специальный файл, состоящий из последова¬ 
тельности нумерованных блоков. Основное свойство блочного специального фай¬ 
ла заключается в том, что к каждому его блоку можно адресоваться и получить 
доступ отдельно. Другими словами, программа может открыть блочный специаль¬ 
ный файл и прочитать, скажем, 124-й блок, не читая сначала блоки с 0 по 123. Блоч¬ 
ные специальные файлы обычно используются для дисков. 

Символьные специальные файлы, как правило, используются для устройств 
ввода или вывода символьного потока. Символьные специальные файлы исполь¬ 
зуются такими устройствами, как клавиатуры, принтеры, сети, мыши, плоттеры 
и т. д. Невозможно (и даже бессмысленно) искать на мыши 124-й блок. 

С каждым специальным файлом связан драйвер устройства, осуществляющий 
управление соответствующим устройством. У каждого драйвера есть так называе¬ 
мый номер старшего устройства, служащий для его идентификации. Если драй¬ 
вер одновременно поддерживает несколько устройств, например два диска одного 
типа, то каждому диску присваивается номер младшего устройства, идентифици¬ 
рующий это устройство. Вместе номера главного устройства и младшего устройства 
однозначно обозначают каждое устройство ввода-вывода. В некоторых случаях 
один драйвер может управлять двумя связанными устройствами. Например, драйвер, 
соответствующий символьному специальному файлу /Пеѵ/ІСу, управляет и клавиа¬ 
турой и экраном, которые часто воспринимаются как единое устройство, терминал. 

Хотя к большинству символьных специальных файлов невозможен произволь¬ 
ный доступ, ими часто бывает нужно управлять таким способом, который не ис¬ 
пользуется для блочных специальных файлов. Рассмотрим, например, строку, вве¬ 
денную с клавиатуры и отображенную на экране. Когда пользователь по ошибке 
нажимает не ту клавишу и хочет заменить последний символ, он нажимает спе¬ 
циальную клавишу. Некоторые пользователи предпочитают использовать для это¬ 
го клавишу ВАСК5РАСЕ, а другие любят пользоваться клавишей О ЕЕ Для удаления 
всей только что набранной строки тоже имеется большой выбор средств. Традици¬ 
онно использовался символ @, но с распространением электронной почты (исполь- 
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зующей символ @ в почтовом адресе) многие системы перешли на использование 
комбинации клавиш СТКІ.+ІІ или других символов. Требуется и особая клавиша для 
прерывания работающей программы. Здесь также у разных пользователей различ¬ 
ные вкусы. 

В операционной системе 1ЖІХ эти символы не заданы жестко, а могут быть 
настроены пользователем. Для установки этих параметров обычно предоставля¬ 
ется специальный системный вызов. Этот системный вызов также управляет пре¬ 
образованием табулятора в пробелы, включением и выключением эха при вводе, 
преобразованиями символов перевода каретки в перенос строки и т. д. Для обыч¬ 
ных файлов и блочных специальных файлов этот системный вызов недоступен. 

Работа с сетью 

Другим примером ввода-вывода является работа с сетью, впервые появившаяся 
в Вегкеіеу 1)№Х. Этот вопрос мы и рассмотрим ниже. Ключевым понятием в схеме 
Вегкеіеу ІЖІХ является сокет. Сокеты подобны почтовым ящикам и телефонным 
розеткам в том смысле, что они образуют пользовательский интерфейс с сетью, как 
почтовые ящики формируют интерфейс с почтовой системой, а телефонные ро¬ 
зетки позволяют абоненту подключить телефон и соединиться с телефонной сис¬ 
темой. Схематично расположение сокетов показано на рис. 10.11. 


Отправляющий процесс Отправляющий процесс 



Сеть 


Рис. 10.11. Использование сокетов для соединения с сетью 

Сокеты могут динамически создаваться и разрушаться. При создании сокета 
вызывающему процессу возвращается дескриптор файла, требующийся для уста¬ 
новки соединения, чтения и записи данных, а также разрыва соединения. 

Каждый сокет поддерживает определенный тип работы в сети, указываемый 
при создании сокета. Наиболее распространенными типами сокетов являются: 

1. Надежный, ориентированный на соединение байтовый поток. 

2. Надежный, ориентированный на соединение поток пакетов. 

3. Ненадежная передача пакетов. 

Первый тип сокетов позволяет двум процессам на различных машинах устано¬ 
вить между собой эквивалент «трубы» (канала между процессами на одной маши- 
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не). Байты подаются в канал с одного конца и в том же порядке выходят с другого. 
Такая система гарантирует, что все посланные байты прибудут на другой конец 
капала и прибудут именно в том порядке, в котором были отправлены. 

Второй тип сокетов отличается от первого тем, что он сохраняет границы меж¬ 
ду пакетами. Если отправитель пять раз отдельно обращается к системному вызо¬ 
ву мгИе, каждый раз отправляя по 512 байт, а получатель запрашивает 2560 байт 
по сокету типа 1, он получит все 2560 байт сразу. При использовании сокета типа 2 
ему будут выданы только первые 512 байт. Чтобы получить остальные байты, 
получателю придется выполнить системный вызов геасі еще четыре раза. Третий 
тип сокета предоставляет пользователю доступ к «голой» сети. Этот тип сокета 
особенно полезен для приложений реального времени и ситуаций, в которых 
пользователь хочет реализовать специальную схему обработки ошибок. Сеть может 
терять пакеты или доставлять их в неверном порядке. В отличие от сокетов первых 
двух типов, сокет типа 3 не предоставляет никаких гарантий доставки. Преиму¬ 
щество этого режима заключается в более высокой производительности, которая 
в некоторых ситуациях оказывается важнее надежности (например, для доставки 
мультимедиа, при которой скорость ценится существенно выше, нежели сохран¬ 
ность данных по дороге). 

При создании сокета один из параметров указывает протокол, используемый 
для него. Для надежных байтовых потоков, как правило, используется протокол 
ТСР (Тгапзтіззіоп Сопігоі Ргоіосоі — протокол управления передачей). Для 
ненадежной передачи пакетов обычно применяется протокол ІШР (Шег Оаіа 
РгоГосоІ — пользовательский протокол данных). Все эти протоколы были разра¬ 
ботаны для сети АКРАКЕТ Министерства обороны США и теперь составляют 
основу Интернета. Для надежного потока пакетов специального протокола нет. 

Прежде чем сокет может быть использован для работы в сети, с ним должен 
быть связан адрес. Этот адрес может принадлежать к одному из нескольких про¬ 
странств адресов. Наиболее распространенным пространством является простран¬ 
ство адресов Интернета, использующее 32-разрядные числа для идентификации 
конечных адресатов в протоколе ІР ѵ 4 и 128-разрядные числа в протоколе ІР ѵ 6 
(5-я версия протокола ІР была экспериментальной системой, так и не выпущен¬ 
ной в свет). 

Как только сокеты созданы на компьютере-источнике и компьютере-приемни¬ 
ке, между ними может быть установлено соединение (для ориентированной на 
соединение связи). Одна сторона обращается к системному вызову Іізѣеп, указы¬ 
вая в качестве параметра локальный сокет. При этом системный вызов создает 
буфер и блокируется до тех пор, пока не прибудут данные. Другая сторона обра¬ 
щается к системному вызову соппесЕ задавая в параметрах дескриптор файла для 
локального сокета и адрес удаленного сокета. Если удаленный компьютер прини¬ 
мает вызов, тогда система устанавливает соединение между двумя сокетами. 

Функции установленного соединения аналогичны функциям канала. Процесс 
может читать из канала и писать в него, используя дескриптор файла для локаль¬ 
ного сокета. Когда соединение более не нужно, оно может быть закрыто обычным 
способом, при помощи системного вызова сіозе. 
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Системные вызовы ввода-вывода системы ІІЫІХ 

С каждым устройством ввода-вывода в операционной системе ІШІХ обычно свя¬ 
зан специальный файл. Большую часть операций ввода-вывода можно выполнить 
при помощи соответствующего файла, что позволяет избежать необходимости 
использования специальных системных вызовов. Тем не менее иногда возникает 
необходимость в обращении к неким специфическим устройствам. До принятия 
стандарта Р05ІХ в большинстве версий системы ІШІХ был системный вызов 
Іосій, выполнявший со специальными файлами большое количество операций, 
специфических для различных устройств. С годами все это привело к путанице. 
В стандарте Р05ІХ этот вопрос был приведен в порядок, для чего функции сис¬ 
темного вызова іосій были разбиты на отдельные функциональные вызовы, глав¬ 
ным образом для управления терминалом. Является ли каждый из них отдельным 
системным вызовом или все они вместе используют один системный вызов, зави¬ 
сит от конкретной реализации. 

Первые четыре вызова, перечисленные в табл. 10.7, используются для задания 
скорости терминала. Для управления вводом и выводом предоставлены различ¬ 
ные вызовы, так как некоторые модемы работают в несимметричном режиме. На¬ 
пример, старые системы ѵісіеоіех предоставляли пользователям доступ к откры¬ 
тым базам данных с короткими запросами от дома до сервера на скорости 75 бит/с 
и ответами, посылаемыми со скоростью 1200 бит/с. Этот стандарт был принят в 
то время, когда скорость 1200 бит/с в обоих направлениях была слишком дорогой 
для домашнего использования. Такая асимметрия все еще сохраняется на многих 
линиях связи. Например, некоторые телефонные компании предоставляют услу¬ 
ги цифровой связи А05Ь (Азуттеігіс Эіфіаі ЗиЬзсгіЬег Ьіпе — асимметричная 
цифровая абонентская линия) с входящим потоком на скорости 1,5 Мбит/с и исхо¬ 
дящим потоком в 384 кбит/с. 


Таблица 10.7. Основные вызовы стандарта РОЗІХ для управления терминалом 


Вызов 

Описание 

5=с1зе1озреесі(&1егтіо5, зреесі) 

Задать исходящую скорость 

з=сІзеІізреесі(&ІегтІ05, зреесі) 

Задать входящую скорость 

з=с!деІозреесі(&Іегтіоз, зреесі) 

Получить исходящую скорость 

8=сІдІеІізреесі(&ІегтІ05, зреесі) 

Получить входящую скорость 

з=ісзеіаі1г(1сі, орі, &Іегтіоз) 

Задать атрибуты 

5=1сде1а11г(М, &Іегтіоз) 

Получить атрибуты 


Последние два системных вызова в списке предназначены для задания и считы¬ 
вания всех специальных символов, используемых для удаления символов и строк, 
прерывания процессов и т. д. Помимо этого они позволяют разрешить и запретить 
вывод эха, осуществлять управление потоком, а также выполнять другие связан¬ 
ные с символьным вводом-выводом функции. Также существуют дополнительные 
функциональные вызовы ввода-вывода, но они в некотором роде специализирован¬ 
ные, поэтому мы не станем рассматривать их в дальнейшем. Следует также отме¬ 
тить, что системный вызов Іосій по сию пору существует во многих системах ІШІХ. 
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Реализация ввода-вывода в системе ІІМІХ 

Ввод-вывод в операционной системе ІЖІХ реализуется набором драйверов уст¬ 
ройств, по одному для каждого типа устройств. Функция драйвера заключается в 
изолировании остальной части системы от индивидуальных отличительных осо¬ 
бенностей аппаратного обеспечения. При помощи стандартных интерфейсов меж¬ 
ду драйверами и остальной операционной системой большая часть системы вво¬ 
да-вывода может быть помещена в машинно-независимую часть ядра. 

Когда пользователь получает доступ к специальному файлу, файловая система 
определяет номера старшего и младшего устройств, а также выясняет, является ли 
файл блочным специальным файлом или символьным специальным файлом. Но¬ 
мер старшего устройства используется в качестве индекса для одного из двух внут¬ 
ренних массивов структур — Ъйеѵзтю для блочных специальных файлов или сйеѵзш 
для символьных специальных файлов. Найденная таким образом структура содер¬ 
жит указатели на процедуры открытия устройства, чтения из устройства, записи 
на устройство и т. д. Номер младшего устройства передается в виде параметра. 
Добавление нового типа устройства к системе ІЖІХ означает добавление нового 
элемента к одной из этих таблиц, а также предоставление соответствующих про¬ 
цедур выполнения различных операций с устройством. 

Наиболее важные поля массива сйеѵш для типичной системы могут выглядеть, 
как показано в табл. 10.8. Каждый ряд таблицы относится к одному устройству 
ввода-вывода (то есть одному драйверу). Колонки соответствуют функциям, ко¬ 
торые должны поддерживаться всеми драйверами. Существуют также некоторые 
другие функции. Когда выполняется операция с символьным специальным фай¬ 
лом, система обращается к массиву аіеѵзтю, выбирая соответствующий ряд (струк- 
туру), затем обращается к функции в соответствующей записи структуры (колон¬ 
ка таблицы), чтобы выполнить требуемое действие. Таким образом, каждый ряд 
таблицы содержит указатели на функции, содержащиеся в одном драйвере. 


Таблица 10.8. Некоторые из полей типичной таблицы ссіеѵзѵѵ 


Устройство 

Ореп 

СІозе 

ВеаЦ 

ѴѴгіТе 

ІосН 

ОНіег 

№11 

пиІІ 

пиІІ 

пиІІ 

пиІІ 

пиІІ 


Память 

пиІІ 

пиІІ 

плепл_геасІ 

плет_ѵѵгі1е 

пиІІ 


Клавиатура 

кореп 

к_сІозе 

к_геасІ 

ѲГГОГ 

к_іосІІ 


тіу 

Пуореп 

Пусіозе 

ПугеасІ 

Пу_ѵѵгі1е 

Пу_іосІІ 


Принтер 

Ір_ореп 

Ірсіозе 

ѳггог 

Ірѵѵгііе 

ІріосІІ 



Каждый драйвер разделен на несколько частей. Верхняя часть драйвера работа¬ 
ет в режиме вызывающего процесса и служит интерфейсом с остальной системой 
ІЖІХ. Нижняя часть работает в контексте ядра и взаимодействуете устройством. 
Драйверам разрешается обращаться к процедурам ядра для выделения памяти, 
управления таймером, управления ОМА и т. д. Набор функций ядра, которые они 
могут вызывать, определен в документе, называемом Интерфейс Драйвер-Ядро. 
Создание драйверов для системы ІЖІХ подробно описано в [105]. 
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Система ввода-вывода разделена на два основных компонента: обработку блоч¬ 
ных специальных файлов и обработку символьных специальных файлов. Мы по 
очереди рассмотрим эти компоненты. 

Цель той части системы, которая занимается операциями ввода-вывода с блоч¬ 
ными специальными файлами (например, дисковым вводом-выводом), заключа¬ 
ется в минимизации количества операций переноса данных. Для достижения дан¬ 
ной цели в системах ІІШХ между дисковыми драйверами и файловой системой 
помещается буферный кэш (рис. 10.12). Буферный кэш представляет собой таб¬ 
лицу в ядре, в которой хранятся тысячи недавно использованных блоков. Когда 
файловой системе требуется блок диска (например, блок і-узла, каталога или дан¬ 
ных), сначала проверяется буферный кэш. Если нужный блок есть в кэше, он по¬ 
лучается оттуда, при этом обращения к диску удается избежать. Буферный кэш 
значительно улучшает производительность системы. 



Рис. 10.12. Система ввода-вывода ВЗР ІІЫІХ 

Если же блока нет в буферном кэше, он считывается с диска в кэш, а оттуда 
копируется туда, куда нужно. Поскольку в буферном кэше есть место только для 
фиксированного количества блоков, требуется некий алгоритм управления кэшем. 
Обычно блоки в кэше организуются в связный список. При каждом обращении к 
блоку он перемещается в начало списка. Если в кэше не хватает места для нового 
блока, то из него удаляется самый старый блок, находящийся в конце списка. 
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Буферный кэш поддерживает не только операцию чтения с диска, но также и 
запись на диск. Когда программа пишет блок, этот блок не попадает напрямую на 
диск, а отправляется в кэш. Только когда кэш наполняется, модифицированные 
блоки кэша сохраняются на диске. Чтобы модифицированные блоки не хранились 
в кэше слишком долго, принудительная выгрузка на диск «грязных» блоков про¬ 
изводится каждые 30 с. 

В течение десятилетий драйверы устройств системы ИЫІХ статически компоно¬ 
вались вместе с ядром, так что все они постоянно находились в памяти при каждой 
загрузке системы. Такая схема хорошо работала в условиях мало меняющихся кон¬ 
фигураций факультетских мини-компьютеров, а затем сложных рабочих станций, 
то есть в тех условиях, в которых росла и развивалась операционная система БЫІХ. 
Как правило, компьютерный центр формировал ядро операционной системы, содер¬ 
жащее драйверы для всех необходимых в данной конфигурации устройств ввода- 
вывода, которыми потом и пользовался. Если на следующий год покупался новый 
диск, компьютерный центр перекомпоновывал ядро, что было не так уж и сложно. 

Все изменилось с появлением системы Ыпих, ориентированной в первую 
очередь на поддержку персональных компьютеров. Количество всевозможных 
устройств ввода-вывода на персональных компьютерах на порядок больше, чем у 
мини-компьютеров. Кроме того, хотя у пользователей системы Еіпих есть (или они 
легко могут его получить) полный набор исходных текстов операционной систе¬ 
мы, подавляющее большинство пользователей будет испытывать существенные 
трудности с добавлением нового драйвера, обновлением файлов сйеѵзт или Ъсіеѵзхю, 
компоновкой ядра и установкой его как загружаемой системы (не говоря уже о том, 
что придется делать, если построенное новое ядро откажется загружаться). 

В операционной системе Біпих подобные проблемы были решены при помощи 
концепции подгружаемых модулей. Это куски кода, которые могут быть загру¬ 
жены в ядро во время работы операционной системы. Как правило, это драйверы 
символьных или блочных устройств, но подгружаемым модулем также могут быть 
целая файловая система, сетевые протоколы, программы для отслеживания про¬ 
изводительности системы и т. д. 

При загрузке модуля должно выполняться несколько определенных действий. 
Во-первых, модуль должен быть на лету перенастроен на новые адреса. Во-вторых, 
система должна проверить, доступны ли ресурсы, необходимые драйверу (напри¬ 
мер, определенные уровни запроса прерывания), и если они доступны, то поме¬ 
тить их как используемые. В-третьих, должны быть настроены все необходимые 
векторы прерываний. В-четвертых, для поддержки нового типа старшего устрой¬ 
ства следует обновить таблицу переключения драйверов. Наконец, драйверу по¬ 
зволяется выполнить любую специфическую для данного устройства процедуру 
инициализации. Когда все эти этапы выполнены, драйвер является полностью ус¬ 
тановленным, как и драйвер, установленный статически. Некоторые современные 
системы ІШІХ также поддерживают подгружаемые модули. 


Потоки данных 

Так как символьные специальные файлы имеют дело с символьными потоками, 
а не перемещают блоки данных между памятью и диском, они не пользуются бу¬ 
ферным кэшем. Вместо этого в первых версиях системы ІЖІХ каждый драйвер 



Ввод-вывод в системе ІЛЧІХ 


801 


символьного устройства выполнял всю работу, требуемую для данного устройства. 
Однако с течением времени стало ясно, что многие драйверы, например програм¬ 
мы буферизации, управления потоком и сетевые протоколы, дублировали проце¬ 
дуры друг друга. Поэтому для структурирования драйверов символьных устройств 
и придания им модульности было разработано два решения. Мы кратко рассмот¬ 
рим их по очереди. 

Решение, реализованное в системе ВЗБ, основано на структурах данных, при¬ 
сутствующих в классических системах ІЖІХ, называемых С-списками (они по¬ 
казаны в виде квадратиков на рис. 10.12). Каждый С-список представляет собой 
блок размером до 64 символов плюс счетчик и указатель на следующий блок. 
Символы, поступающие с терминала или любого другого символьного устройства, 
буферизируются в цепочках таких блоков. 

Когда пользовательский процесс считывает данные из /аІеѵ/Пу (то есть из 
стандартного входного потока), символы не передаются процессу напрямую из 
С-списков. Вместо этого они пропускаются через процедуру, расположенную 
в ядре и называющуюся дисциплиной линии связи. Дисциплина линии связи ра¬ 
ботает как фильтр, принимая необработанный поток символов от драйвера терми¬ 
нала, обрабатывая его и формируя то, что называется обработанным символьным 
потоком. В обработанном потоке выполняются операции локального строково¬ 
го редактирования (например, удаляются отмененные пользователем символы 
и строки), символы возврата каретки заменяются символами переноса строки, 
а также выполняются другие специальные операции обработки. Обработанный 
поток передается процессу. Однако если процесс желает воспринимать каждый 
символ, введенный пользователем, он может принимать необработанный поток, 
минуя дисциплину линии связи. 

Вывод работает аналогично, заменяя табуляторы пробелами, добавляя перед 
символами переноса строки символы возврата каретки, добавляя для медленных 
механических терминалов символы-заполнители, за которыми следует символ 
возврата каретки и т. д. Как и входной поток, выходной символьный поток может 
быть пропущен через дисциплину линии связи (обработанный режим) или мино¬ 
вать ее (необработанный режим). Необработанный режим особенно полезен при 
отправке двоичных данных на другие компьютеры по линии последовательной 
передачи или для графических интерфейсов пользователя. Здесь не требуется ни¬ 
какого преобразования. 

Решение, реализованное в системе Зузіет V под называнием потоков данных, 
было разработано Деннисом Ритчи. Это общий подход (рис. 10.13). (В Зузіеш V 
также есть буферный кэш для блочных специальных файлов, но поскольку он, по 
сути, не отличается от схемы, применяемой в ВЗЭ, кэш не показан здесь.) Потоки 
данных основаны на возможности динамически соединять процесс пользователя 
с драйвером, а также динамически, во время исполнения, вставлять модули обра¬ 
ботки в поток данных. В некотором смысле поток представляет собой работающий 
в ядре аналог каналов в пространстве пользователя. 

У потока данных всегда есть голова потока у вершины и соединение с драйве¬ 
ром у основания. В поток может быть вставлено столько модулей, сколько необ¬ 
ходимо. Обработка может происходить в обоих направлениях, так что каждому 
модулю может понадобиться одна секция для чтения (из драйвера) и одна секция 
для записи (в драйвер). Когда процесс пользователя пишет данные в поток, про¬ 
грамма в голове потока интерпретирует системный вызов и запаковывает данные 
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в буферы потока, передаваемые от модуля к модулю вниз, при этом каждый мо¬ 
дуль выполняет соответствующие преобразования. У каждого модуля есть очередь 
чтения и очередь записи, так что буферы обрабатываются в правильном порядке. 
У модулей есть строго определенные интерфейсы, определяемые инфраструкту¬ 
рой потока, что позволяет объединять вместе несвязанные модули. 


Режим 

пользователя 


< 


Режим 

ядра 


Компьютер 



Локальная сеть Токеп гіпд 
(маркерное кольцо) 


Рис. 10 . 13 . Пример потоков в Зузіет V 


В примере на рис. 10.13 показано, как применяются потоки при использовании 
Интернет-протокола ТСР с двумя локальными сетями различного типа: ЕіЬегпеІ 
и Токеп гіп§. Данный пример иллюстрирует еще одно важное свойство потоков 
данных — мультиплексирование. Мультиплексный модуль может взять один по¬ 
ток и расщепить его на несколько потоков или, наоборот, объединить несколько 
потоков в единый поток. Модуль ІР в данном примере выполняет обе функции. 


Файловая система ІІЫІХ 

Прежде всего пользователь видит в любой операционной системе, включая систе¬ 
му ІЛЧІХ, файловую систему. В следующих разделах мы рассмотрим основные 
идеи файловой системы ІІМІХ, системные вызовы и детали реализации файловой 
системы. Некоторые принципы файловой системы ІІМІХ были взяты у операцион¬ 
ной системы М1ШПС5, в то время как многие другие позаимствованы в М5-005, 
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АѴіпс1о\ѵ5 и других системах, хотя имеются и уникальные для ІЖІХ идеи. Устрой¬ 
ство файловой системы ІЖІХ особенно интересно тем, что оно отчетливо ил¬ 
люстрирует принцип разумной достаточности и красоту простых решений. При 
минимальном механизме и сильно ограниченном количестве системных вызовов 
операционная система ІЖІХ тем не менее предоставляет мощную и элегантную 
файловую систему. 


Основные понятия 

Файл в системе ІЖІХ — зто последовательность байтов произвольной длины (от О 
до некоторого максимума), содержащая произвольную информацию. Не делается 
принципиального различия между текстовыми ( А8СІІ) файлами, двоичными фай¬ 
лами и любыми другими файлами. Значение битов в файле целиком определяется 
владельцем файла. Системе это безразлично. Изначально размер имен файлов был 
ограничен 14 символами, но в системе Вегкеіеу ІЖІХ этот предел был расширен 
до 255 символов, что впоследствии было принято в ЗузСеш V, а также в большин¬ 
стве других версий. В именах файлов разрешается использовать все АЗСІІ-симво- 
лы, кроме символа N131., поэтому допустимы даже имена файлов, состоящие, на¬ 
пример, из трех символов возврата каретки (хотя такое имя и не слишком удобно 
в использовании). 

По соглашению многие программы ожидают, что имена файлов должны состоять 
из основного имени и расширения, отделяемого от основного имени файла точкой 
(которая в системе ІЖІХ также считается символом). Так,рго$.с — это, как пра¬ 
вило, программа на языке С,рго§./90 — обычно программа на языке РОКТК.А1Ч 90, 
а рго§.о — чаще всего объектный файл (выходные данные компилятора). Эти со¬ 
глашения никак не регулируются операционной системой, но некоторые компи¬ 
ляторы и другие программы ожидают файлов именно с такими расширениями. 
Расширения могут иметь произвольную длину, кроме того, файлы могут иметь по 
нескольку расширений, как, например, ргор,.)аѵа.2, что, скорее всего, представляет 
собой сжатую программу на языке ^ѵа. 

Для удобства использования файлы могут группироваться в каталоги. Катало¬ 
ги хранятся на диске в виде файлов, и до определенного предела с ними можно 
работать как с файлами. Каталоги могут содержать подкаталоги, что приводит к 
иерархической файловой системе. Корневой каталог называется / и, как правило, 
содержит несколько подкаталогов. Символ / также используется для разделения 
имен каталогов, поэтому имя /изг/азі/х означает файл х, расположенный в ката¬ 
логе азі, который, в свою очередь, находится в каталоге изг. 

Некоторые основные каталоги у вершины дерева показаны в табл. 10.9. 

Таблица 10.9. Некоторые важные каталоги, существующие в большинстве систем ШІХ 

Каталог Содержание 

Ьіп Двоичные (исполняемые) программы 

сіеѵ Специальные файлы для устройств ввода-вывода 

еіс Разные системные файлы 

ІІЬ Библиотеки 

изг Каталоги пользователей 
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Существует два способа задания имени файла в системе ІЖІХ, как в оболочке, 
так и при открытии файла из программы. Первый способ заключается в использо¬ 
вании абсолютного пути, указывающего, как найти файл от корневого каталога. 
Пример абсолютного пути: /изг/азі/Ъоокз/тоз2/скар- 10. Он сообщает системе, что 
в корневом каталоге следует найти каталог изг, затем в нем найти каталог азі, ко¬ 
торый содержит каталог Ьоокз, в котором содержится каталог тоз2, а в нем, нако¬ 
нец, расположен файл скар-10. 

Абсолютные имена путей часто бывают длинными и неудобными. По этой при¬ 
чине операционная система ІШІХ позволяет пользователям и процессам обозначить 
каталог, в котором они работают в данный момент, как рабочий каталог (также 
называемый текущим каталогом). Имена путей также могут указываться относи¬ 
тельно рабочего каталога. Путь файла, заданный относительно рабочего каталога, 
называется относительным путем. Например, если каталог / изг /азі/ Ьоокз/тоз2 
является рабочим каталогом, тогда команда оболочки 

ср сИар-10 Ьаскирі 

возымеет тот же самый эффект, что и более длинная команда 
ср /изг/азі/Ьоокз/тозг/сІіар-ІО /изг/азі/Ьоокз/тоз2/Ьаскир! 

Пользователям часто бывает необходимо обратиться к файлам, принадлежа¬ 
щим другим пользователям, или к своим файлам, расположенным в другом месте 
дерева файлов. Например, если два пользователя совместно используют один файл, 
он будет находиться в каталоге, принадлежащем одному из них, поэтому другому 
пользователю понадобится для обращения к этому файлу использовать абсолют¬ 
ное имя пути (или менять свой рабочий каталог). Если абсолютный путь доста¬ 
точно длинен, то необходимость вводить его каждый раз может весьма сильно раз¬ 
дражать. В системе ІШІХ эта проблема решается при помощи так называемых 
связей, представляющих собой записи каталога, указывающие на другие файлы. 

В качестве примера рассмотрим ситуацию на рис. 10.14, а. Фред и Лиза вместе 
работают над одним проектом, и каждому из них нужен доступ к файлам другого. 
Если рабочий каталог Фреда /изг//геб, он может обращаться к файлу х в каталоге 
Лизы как /изг/ііза/х. Однако Фред может также создать новую запись в своем ката¬ 
логе (рис. 10.14, б), после чего он сможет обращаться к этому файлу просто как к х. 

В только что обсуждавшемся примере мы предположили, что до создания связи 
единственный способ, которым Фред мог обратиться к файлу х Лизы, заключался в 
использовании абсолютного пути. В действительности это не совсем так. При со¬ 
здании каталога в нем автоматически создаются две записи,«.» и «..». Первая запись 
обозначает сам каталог. Последняя является ссылкой на родительский каталог, то 
есть каталог, в котором данный каталог числится как запись. Таким образом, из 
каталога /изг//геб к файлу х Лизы можно обратиться еще и по пути ../Ііза/х. 

Кроме обычных файлов, системой ІШІХ также поддерживаются символьные 
специальные файлы и блочные специальные файлы. Символьные специальные 
файлы используются для моделирования последовательных устройств ввода-вы¬ 
вода, таких как клавиатуры и принтеры. Если процесс откроет файл /йеѵ/ііу и про¬ 
читает из него, он получит символы, введенные с клавиатуры. Если открыть файл 
/йеѵ/ір и записать в него данные, то эти данные будут распечатаны на принтере. 
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Блочные специальные файлы, часто с такими именами, как /сіеѵ/ксіі, могут исполь¬ 
зоваться для чтения и записи необработанных дисковых разделов, минуя файло¬ 
вую систему. Таким образом, поиск байта номер к, за которым последует чтение, 
приведет к чтению к-то байта на соответствующем дисковом разделе, игнорируя 
і-узел и файловую структуру. Необработанные блочные устройства используют¬ 
ся для страничной подкачки и свопинга программами установки файловой систе¬ 
мы (например, тк/з) и программами, исправляющими ломаные файловые систе¬ 
мы (например, /зек). 


/ / 



а б 

Рис. 10 . 14 . До создания связи (а); после создания связи (б) 


На многих компьютерах установлено по два и более дисков. Например, на мэйн¬ 
фреймах в банках часто бывает необходимо подключать по 100 и более дисков к 
одной машине, чтобы хранить большие базы данных. Даже у персональных ком¬ 
пьютеров есть по меньшей мере два диска — жесткий диск и дисковод для гибких 
дисков. При наличии у компьютера нескольких дисков возникает вопрос, как ими 
управлять. 

Одно из решений заключается в том, чтобы установить самостоятельную файло¬ 
вую систему на каждый отдельный диск и управлять ими как отдельными файло¬ 
выми системами. Рассмотрим, например, ситуацию, изображенную на рис. 10.15, а. 
Здесь показан жесткий диск, который мы будем называть С:, а также гибкий диск, 
который мы будем называть А:. У каждого есть собственный корневой каталог и 
файлы. При таком решении пользователь должен помимо каталогов указывать 
также и устройство, если оно отличается от используемого по умолчанию. Напри¬ 
мер, чтобы скопировать файл х в каталог сі (предполагая, что по умолчанию выби¬ 
рается диск С:), следует ввести команду 

ср А:/х /а/сі/х 

Такой подход применяется в операционных системах М5-В05, Шіпсіо\ѵ5 98 
и ѴМ5. 

Решение, применяемое в операционной системе ІШІХ, заключается в том, 
Чтобы позволить монтировать один диск в дерево файлов другого диска. В на¬ 
шем примере мы можем смонтировать дискету в каталог /Ь, получая в результате 
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файловую систему, показанную на рис. 10.15, б. Теперь пользователь видит еди¬ 
ное дерево файлов и уже не должен думать о том, какой файл на каком устройстве 
хранится. В результате приведенная выше команда примет вид 

ср /Ь/х /а/сі/х 

то есть все будет выглядеть так, как если бы файл копировался из одного каталога 
жесткого диска в другой каталог того же диска. 


Жесткий диск Дискета Жесткий диск 



Рис. 10 . 15 . Раздельные файловые системы (а); после монтирования (б) 


Другое интересное свойство файловой системы ІЖІХ представляет собой бло¬ 
кировка. В некоторых приложениях два и более процессов могут одновременно 
использовать один и тот же файл, что может привести к конфликту. Одно из ре¬ 
шений данной проблемы заключается в том, чтобы создать в приложении крити¬ 
ческие области. Однако если эти процессы принадлежат независимым пользова¬ 
телям, даже не знакомым друг с другом, такой способ координации действий, как 
правило, очень неудобен. 

Рассмотрим, например, базу данных, состоящую из многих файлов в одном или 
нескольких каталогах, доступ к которым могут получить никак не связанные меж¬ 
ду собой пользователи. С каждым каталогом или файлом можно связать семафор 
и достичь взаимного исключения, заставляя процессы выполнять операцию сіоип 
на соответствующем семафоре, прежде чем читать или писать определенные дан¬ 
ные. Недостаток этого решения заключается в том, что при этом недоступным 
становится весь каталог или файл, даже если процессам нужна всего одна запись. 

По этой причине стандартом Р05ІХ предоставляется гибкий и детальный ме¬ 
ханизм, позволяющий процессам за одну неделимую операцию блокировать даже 
единственный байт файла или целый файл, по желанию. Механизм блокировки 
требует от вызывающего его процесса указать блокируемый файл, начальный байт 
и количество байтов. Если операция завершается успешно, система создает запись 
в таблице, в которой указывается, что определенные байты файла заблокированы. 

Стандартом определены два типа блокировки: блокировка с монополизацией 
и блокировка без монополизации. Если часть файла уже содержит блокировку 
без монополизации, то повторная установка блокировки без монополизации на это 
место файла разрешается, но попытка установки блокировку с монополизацией 
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будет отвергнута. Если же какая-либо область файла содержит блокировку с моно¬ 
полизацией, то любые попытки заблокировать любую часть этой области файла бу¬ 
дут отвергаться, пока не будет снята монопольная блокировка. Для успешной уста¬ 
новки блокировки необходимо, чтобы каждый байт в данной области был доступен. 

При установке блокировки процесс должен указать, хочет ли он сразу получить 
управление или будет ждать, пока не будет установлена блокировка. Если процесс 
выбрал вызов с ожиданием, то он блокируется до тех пор, пока с запрашиваемой 
области файла не будет снята блокировка, установленная другим процессом, пос¬ 
ле чего процесс активизируется, и ему сообщается, что блокировка установлена. 
Если процесс решил воспользоваться системным вызовом без ожидания, он не¬ 
медленно получает ответ об успехе или неудаче операции. 

Заблокированные области могут перекрываться. На рис. 10.16, а показано, что 
процесс Л установил блокировку без монополизации на байты с 4 по 7 в некото¬ 
ром файле. Затем процесс В устанавливает блокировку без монополизации на бай¬ 
ты с 6 по 9. Наконец, процесс С устанавливает блокировку без монополизации на 
байты со 2 по 11. Пока это блокировки без монополизации, они могут устанавли¬ 
ваться одновременно. Теперь посмотрим, что произойдет, если какой-либо процесс 
попытается получить блокировку с монополизацией к байту 9, используя систем¬ 
ный вызов с ожиданием, когда блокировка данного участка файла сразу невозмож¬ 
на (рис. 10.16, в). Две предыдущие блокировки перекрываются с этой блокировкой. 
Поэтому обращающийся с новым запросом процесс будет заблокирован и останет¬ 
ся заблокированным, пока оба процесса В и С не снимут свою блокировку. 

Блокировка без монополизации, 
установленная процессом А 
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Глава 10. Рассмотрение конкретных случаев: ІІІМІХ и І-іпих 


Вызовы файловой системы в ІШІХ 

Многие системные вызовы относятся к файлам и файловой системе. Сначала мы 
рассмотрим системные вызовы, работающие с отдельными файлами. Затем мы 
изучим те системные вызовы, которые оперируют каталогами или всей файловой 
системой в целом. Для создания нового файла можно использовать системный 
вызов сгеаС (Когда Кена Томпсона однажды спросили, что бы он поменял, если 
бы у него была возможность во второй раз разработать операционную систему 
ІЖІХ, он ответил, что на этот раз вместо сгеаі: он назвал бы этот системный вызов 
сгеаѣе.) В качестве параметров этому системному вызову следует задать имя фай¬ 
ла и режим защиты. Так, команда 

Ггі = сгеаІС'аЬс” . тосіе): 

создает файл аЪс с режимом защиты, указанном в переменной (или константе) 
тосіе. Биты тосіе определяют круг пользователей, которые могут получить доступ 
к файлу, а также уровень предоставляемого им доступа. Вопросы защиты файлов 
и доступа к ним будут рассмотрены ниже. 

Системный вызов сгеаі: не только создает новый файл, но также и открывает 
его для записи. Чтобы последующие системные вызовы могли получить доступ к 
файлу, успешный системный вызов сгеаі: возвращает небольшое неотрицательное 
целое число, называемое дескриптором файла (/сі в приведенном выше примере). 
Если системный вызов выполняется с уже существующим файлом, длина этого 
файла уменьшается до 0, а все содержимое теряется. 

Теперь продолжим изучение основных файловых системных вызовов, перечис¬ 
ленных в табл. 10.10. (В случае ошибки возвращаемое значение 5 равно -1 ,/сі — дес¬ 
криптор файла, розШоп — смещение в файле.) Чтобы прочитать данные из суще¬ 
ствующего файла или записать данные в существующий файл, файл сначала нужно 
открыть с помощью системного вызова орел. Этому системному вызову следует 
указать имя файла, а также режим, в котором он должен быть открыт: для чтения, 
для записи или и для того и для другого. Также можно указать различные дополни¬ 
тельные параметры. Как и сгеаі:, системный вызов орел возвращает дескриптор фай¬ 
ла, который может быть использован для чтения или записи журнала. Затем файл 
может быть закрыт при помощи системного вызова сіозе, после чего, чтобы писать 
в этот файл или читать из него, его снова нужно открыть. Системные вызовы сгеаі: и 
орел возвращают наименьший неиспользуемый в данный момент дескриптор файла. 


Таблица 10.10. Некоторые системные вызовы для работы с файлами 


Системный вызов 


Описание 


М=сгеаІ(пате, тосіе) 
М=ореп(Ше, боѵѵ, ]) 
з=сІозе(1сІ) 

п=геасІ(Гс(, ЬиНег, пЬуГез) 
П=ѵѵгі1е(1с1, ЬиНег, пЬуІез) 
розіІіоп=Ізеек(ГсІ, оНзеІ, ѵѵЛепсе) 
з=зіаі(пате, &Ьи1) 
з=1зіаі(1сІ, &Ьи1) 
з=ріре(&1Р[0]) 
з=1спіі(1сі, стб,...) 


Один из способов создания нового файла 
Открыть файл для чтения, записи или и того и другого 
Закрыть открытый файл 
Прочитать данные из файла в буфер 
Записать данные из буфера в файл 
Переместить указатель в файле 
Получить информацию о состоянии файла 
Получить информацию о состоянии файла 
Создать канал 

Блокировка файла и другие операции 


І іі 
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Когда программа начинает выполнение стандартным образом, файлы с дескрип¬ 
торами 0, 1 и 2 уже открыты для стандартного ввода, стандартного вывода и стан¬ 
дартного потока сообщений об ошибках соответственно. Таким образом, фильтр, 
например программа зогС, может просто читать свои входные данные из файла с 
дескриптором 0, а писать выходные данные в файл с дескриптором 1, не заботясь 
о том, где располагаются эти файлы. Работа этого механизма обеспечивается обо¬ 
лочкой, которая проверяет, чтобы эти дескрипторы соответствовали нужным фай¬ 
лам, прежде чем программа начнет свою работу. 

Чаще всего программы используют системные вызовы геасі и мгіЪе. У обоих 
вызовов по три параметра: дескриптор файла (указывающий, с каким из откры¬ 
тых файлов будет производиться операция чтения или записи), адрес буфера (со¬ 
общающий, куда положить данные или откуда их взять), а также счетчик байтов 
(указывающий, сколько байтов следует прочитать или записать). Вот и все. Очень 
простая схема. Пример типичного вызова: 

п = геасІШ, ЬиГГег. пЬуТез) 

Хотя большинство программ читают и записывают файлы последовательно, 
некоторым программам бывает необходимо иметь доступ к произвольной части 
файла. С каждым открытым файлом связан указатель на текущую позицию в фай¬ 
ле. При последовательном чтении или записи он указывает на следующий байт, 
который будет прочитан или записан. Например, если указатель установлен на 
4096-й байт, то после успешного чтения 1024 байт из этого файла при помощи си¬ 
стемного вызова геасі он будет указывать на 5120-й байт. Указатель в файле мож¬ 
но переместить с помощью системного вызова Ізеек, что позволяет при следую¬ 
щих обращениях к системным вызовам геасі и мгііе читать данные из файла или 
писать их в файл в произвольной позиции в файле и даже за концом файла. Этот 
системный вызов назван Ізеек, чтобы не путать его с теперь уже устаревшим, ис¬ 
пользовавшимся ранее на 16-разрядных компьютерах системным вызовом зеек. 

У системного вызова 1 зеек три параметра: первый — это дескриптор файла, вто¬ 
рой — новая позиция в файле, а третий сообщает, указывается ли эта позиция от¬ 
носительно начала файла, конца файла или относительно текущей позиции. Зна¬ 
чение, возвращаемое системным вызовом Ізеек, представляет собой абсолютную 
позицию в файле после того, как указатель был перемещен. Забавно, что системный 
вызов Ізеек (зеек означает поиск, термин, также используемый для перемещения 
блока головок диска) никогда не вызывает перемещения блока головок диска, так 
как все, что он делает, — это обновление текущей позиции в файле, представляю¬ 
щей собой просто число в памяти. 

Для каждого файла операционная система ІЖІХ хранит такие сведения, как 
тип (режим) файла (обычный, каталог, специальный файл), его размер, время 
последнего изменения и т. д. Программы могут получить эту информацию при по¬ 
мощи системного вызова зЪаІ:. Первый параметр представляет собой имя файла. 
Второй является указателем на структуру, в которую следует поместить требуе¬ 
мую информацию. Поля этой структуры перечислены в табл. 10.11. Системный 
вызов СзСаС представляет собой то же самое, что и системный вызов зСаС, с гой 
разницей, что он работает с уже открытым файлом (имя которого может быть 
неизвестно), а не с путем. 
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Таблица 10.11 . Поля структуры, возвращаемой системным вызовом зіаі 

Устройство, на котором располагается файл 
Номер і-узла (идентифицирует файл на устройстве) 

Режим файла (включая информацию о защите) 

Количество связей файла 
Идентификатор владельца файла 
Группа, к которой принадлежит файл 
Размер файла в байтах 
Время создания 
Время последнего доступа 
Время последнего изменения 


Системный вызов ріре используется для создания каналов оболочки. Он созда¬ 
ет псевдофайл для буферирования данных, которыми обмениваются компоненты 
канала, и возвращает дескрипторы файлов для чтения и записи буфера. В команде 

50ГІ <іп | ЬеасІ -30 

дескриптор файла 1 (стандартный вывод) в процессе, выполняющем программу 
зогС, будет настроен оболочкой на запись в канал, а дескриптор файла 0 (стандарт¬ 
ный ввод) в процессе, выполняющем программу кеасі, будет настроен на чтение из 
канала. Программа зогС просто читает из файла с дескриптором 0 (установлен на 
файл іп) и пишет в файл с дескриптором 1 (канал), даже не зная, что оба эти файла 
переопределены. Если бы ввод и вывод не были перенаправлены, программа зогС 
читала бы данные с клавиатуры и выводила бы их на экран (устройства по умол¬ 
чанию). Подобным же образом, когда программа кеасі считывает входные данные 
из файла с дескриптором 0, она получает данные, которые программа зогС помес¬ 
тила в буфер канала, даже не зная, что канал используется. Вот пример того, как 
простая концепция (перенаправление потока данных) плюс простая реализация 
(файлы с дескрипторами 0 и 1) вместе дают мощный инструмент (соединение про¬ 
грамм произвольным образом без необходимости их модификации). 

Последний системный вызов в табл. 10.10 — это ГспП. Он используется для 
блокировки и разблокирования файлов, а также некоторых других специфичес¬ 
ких для файлов операций. 

Рассмотрим теперь некоторые системные вызовы, относящиеся скорее к катало¬ 
гам или файловой системе в целом, нежели к какому-либо конкретному файлу. Наи¬ 
более часто употребляемые системные вызовы перечислены в табл. 10.12. (В слу¬ 
чае ошибки возвращаемое значение 5 равно -1, сііг идентифицирует каталог, а сіігепС 
представляет собой запись каталога.) Каталоги создаются и удаляются при помо¬ 
щи системных вызовов тксііг и гтсііг соответственно. Каталог может быть уничто¬ 
жен, только если он пуст. 

Как было показано на рис. 10.14, при создании связи с файлом создается новая 
запись в каталоге, указывающая на существующий файл. Связь создается при по¬ 
мощи системного вызова 1 іпк. В параметрах этого системного вызова указывают¬ 
ся исходное и новое имя. Записи в каталоге удаляются системным вызовом ипі і пк. 
Когда удаляется последняя связь с файлом, файл также автоматически удаляется. 
Если для файла не было создано ни одной связи, то при первом же обращении к 
системному вызову ипі іпк файл будет удален. 
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Таблица 10 . 12 , Некоторые системные вызовы, имеющие отношение 
к работе с каталогом 

Системный вызов 

Описание 

5=тксІіг(раФ, тосіе) 

Создать новый каталог 

з=гтсІіг(раФ) 

Удалить каталог 

з=Ііпк(оІс)раФ, пеѵѵраШ) 

Создать связь с существующим файлом 

з=ипІіпк(раШ) 

Удалить связь 

з=сНс)іг(раФ) 

Изменить рабочий каталог 

сІіг=орепс1іг(раШ) 

Открыть каталог для чтения 

з=сІозес1іг(сІіг) 

Закрыть каталог 

ЦігепІ=геасІсІіг(сІіг) 

Прочитать одну запись каталога 

геѵѵіпсісііг(сііг) 

Установить указатель в каталоге на первую запись 


Рабочий каталог можно изменить при помощи системного вызова сЬсііг. После 
выполнения этого системного вызова будут по-другому интерпретироваться от¬ 
носительные имена путей. 

Последние четыре системных вызова в табл. 10.12 предназначены для чтения 
каталогов. Каталоги могут открываться, закрываться и читаться аналогично обыч¬ 
ным файлам. Каждое обращение к системному вызову геасісііг возвращает ровно 
одну запись каталога фиксированного формата. Пользователям запрещено писать 
в каталоги (это делается, чтобы пользователи случайно не нарушили целостности 
системы). Файлы могут добавляться к каталогу при помощи системных вызовов 
сгеаі и Ііпк, а удаляться с помощью системного вызова ипііпк. В операционной 
системе ІЖІХ нет способа обращаться к файлу по расположению его описателя 
в каталоге, но есть системный вызов геміпсісііг, позволяющий начать читать откры¬ 
тый каталог с начала. 

Реализация файловой системы ІІЫІХ 

В данном разделе будет описана реализация традиционной файловой системы 
ІІШХ. Затем мы обсудим усовершенствования, реализованные в версии Вегкеіеу. 
Также используются и другие файловые системы. Все системы ИБПХ могут под¬ 
держивать несколько дисковых разделов, каждый со своей файловой системой. 

В классической системе ІІКІХ раздел диска содержит файловую систему, распо¬ 
ложение которой изображено на рис. 10.17. Блок 0 не используется системой и час¬ 
то содержит программу загрузки компьютера. Блок 1 представляет собой супер¬ 
блок. В нем хранится критическая информация о размещении файловой системы, 
включая количество і-узлов, количество дисковых блоков, а также начало списка 
свободных блоков диска (обычно несколько сот записей). При уничтожении супер¬ 
блока файловая система окажется нечитаемой. 

Следом за суперблоком располагаются і-узлы (і-посіез, сокращение от іпсіех- 
посіез — индекс-узлы). Они нумеруются от 1 до некоторого максимального числа. 
Каждый і-узел имеет 64 байт в длину и описывает ровно один файл, і-узел содер¬ 
жит учетную информацию (включая всю информацию, возвращаемую системным 
вызовом 5ІаС который ее просто берет в і-узле), а также достаточное количество 
информации, чтобы найти все блоки файла на диске. 
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Загрузочный 

блок Суперблок 
/ Х' і-узлы 


Блоки данных 



' \ и 

Блок 0 Блок 1 

Рис. 10.17. Расположение классической файловой системы ІІМІХ на диске 

Следом за і -узлами располагаются блоки с данными. Здесь хранятся все фай¬ 
лы и каталоги. Если файл или каталог состоит более чем из одного блока, блоки 
файла не обязаны располагаться на диске подряд. В действительности блоки боль¬ 
шого файла, как правило, оказываются разбросанными по всему диску. Именно 
эту проблему должны были решить усовершенствования версии Вегкеіеу. 

Каталог в традиционной файловой системе (то есть Ѵ7) представляет собой 
несортированный набор 16-байтовых записей. Каждая запись состоит из 14-байт- 
ного имени файла и номера і-узла (см. рис. 6.33). Чтобы открыть файл в рабочем 
каталоге, система просто считывает каталог, сравнивая имя искомого файла с каж¬ 
дой записью, пока не найдет нужную запись или пока не закончится каталог. 

Если искомый файл присутствует в каталоге, система извлекает его і-узел и 
использует его в качестве индекса в таблице і-узлов (на диске), чтобы найти 
соответствующий і-узел и считать его в память. Этот і-узел помещается в таблицу 
і-узлов, структуру данных в ядре, содержащую все і-узлы открытых в данный мо¬ 
мент файлов и каталогов. Формат і-узлов варьируется от одной версии ІІМІХ к 
другой. Как минимум і-узел должен содержать все поля, возвращаемые системным 
вызовом (см. табл. 10.11). В табл. 10.13 показана структура і-узла, используе¬ 
мая в АТ&Т версиях системы ІІМІХ от Ѵегзіоп 7 до Зузіеш V. 

Таблица 10.13. Структура і-узла в Зузіет V 


Поле Байты Описание 


Мосіе 2 Тип файла, биты защиты, биты зеіиісі и зеідісі 

ЫІІпкз 2 Количество каталоговых записей, указывающих на этот і-узел 

ІГісі 2 ІЮ владельца файла 

Оіб 2 ОЮ владельца файла 

5іге 4 Размер файла в байтах 

АсЮг 39 Адрес первых 10 дисковых блоков файла и 3 косвенных блоков 

Оеп 1 Номер «поколения» (увеличивается на единицу при каждом 

использовании і-узла) 

Аііте 4 Время последнего доступа к файлу 

Мііте 4 Время последнего изменения файла 


Сііте 4 Время последнего изменения і-узла (не считая других раз) 


Поиск файла по абсолютному пути, например /изг/аз(//Ие, немного сложнее. 
Сначала система находит корневой каталог, как правило, использующий і-узел с но¬ 
мером 2 (і-узел 1 обычно резервируется для хранения дефектных блоков). Затем 
он ищет в корневом каталоге строку «изг», чтобы получить номер і-узла каталога /изг. 
Затем считывается этот і-узел, и из него извлекаются номера блоков, в которых 
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располагается каталог /шг. После этого считывается каталог /шг, в котором ищет¬ 
ся строка «азі». Когда нужная запись найдена, из нее извлекается номер і-узла для 
каталога /шг/азі и т. д. Таким образом, использование относительного имени фай¬ 
ла не только удобнее для пользователя, но также представляет существенно мень¬ 
шее количество работы для файловой системы. 

Рассмотрим теперь, как система считывает файл. Вспомним, что типичное об¬ 
ращение к библиотечной процедуре для запуска системного вызова геасі выглядит 
следующим образом: 

п = геасКТсІ . ЬиІТег. пЬуГез): 

Когда ядро получает управление, ему подаются только эти три параметра. Все 
остальные необходимые данные оно может получить из внутренних таблиц, отно¬ 
сящихся к пользователю. Одной из таких таблиц является массив дескрипторов 
файла. Он проиндексирован по номерам дескрипторов файла и содержит по од¬ 
ной записи для каждого открытого файла (до некоторого максимума, как правило, 
около 20 файлов). 

По дескриптору файла файловая система должна найти і-узел соответствую¬ 
щего файла. Рассмотрим одно из возможных решений: просто поместим в табли¬ 
цу дескрипторов файла указатель на і-узел. Несмотря на простоту, данный метод, 
увы, не работает. Проблема заключается в следующем. С каждым дескриптором 
файла должен быть связан указатель в файле, определяющий байт в файле, кото¬ 
рый будет считан или записан при следующем обращении к файлу. Где следует 
хранить этот указатель? Один вариант состоит в помещении его в таблице і-узлов. 
Однако такой подход не сможет работать, если несколько не связанных друг с дру¬ 
гом процессов одновременно откроют один и тот же файл, так как у каждого про¬ 
цесса должен быть свой собственный указатель. 

Второй вариант решения заключается в помещении указателя в таблицу деск¬ 
рипторов файла. При этом каждый процесс, открывающий файл, получает соб¬ 
ственную позицию в файле. К сожалению, такая схема также не работает, но при¬ 
чина неудачи в данном случае не столь очевидна и имеет отношение к природе 
совместного использования файлов в системе ИМХ. Рассмотрим сценарий обо¬ 
лочки 5 , состоящий из двух команд, рі и р2, которые должны работать по очереди. 
Если сценарий вызывается командной строкой 

3 >х 

то ожидается, что команда р 1 будет писать свои выходные данные в файл х, а ко¬ 
манда р2 будет также писать свои выходные данные в файл х, начиная с того мес¬ 
та, на котором остановилась команда рі. 

Когда оболочка запустит процесс рі, файл х будет изначально пустым, поэтому 
команда рі просто начнет запись в файл в позиции 0. Однако когда она закончит 
свою работу, требуется некий механизм передачи указателя в файле хот процесса 
рі процессу р2. Если же позицию в файле хранить просто в таблице дескрипторов 
файла, процесс р2 начнет запись в файл с позиции 0. 

Способ передачи указателя от одного процесса другому показан на рис. 10.18. 
Трюк состоит в том, чтобы ввести в обращение новую таблицу, таблицу открытых 
файлов, между таблицей дескрипторов файлов и таблицей і-узлов, и хранить 
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указатели в файле, а также бит чтения/записи в ней. На рисунке родительский 
процесс представляет собой оболочку, а дочерний процесс сначала является про¬ 
цессом рі, а затем процессом р2. Когда оболочка создает процесс рі, его пользова¬ 
тельская структура (включая таблицу дескрипторов файлов) представляет собой 
точную копию такой же структуры оболочки, поэтому обе они содержат указате¬ 
ли на одну и ту же таблицу открытых файлов. Когда процесс р\ завершает свою 
работу, таблица дескрипторов файлов оболочки продолжает указывать на табли¬ 
цу открытых файлов, в которой содержится позиция в файле процесса рі. Когда 
теперь оболочка создает процесс р2, новый дочерний процесс автоматически на¬ 
следует позицию в файле. При этом ни сам новый процесс, ни оболочка даже не 
должны знать текущее значение этой позиции. 


Таблица 

дескрипторов 

файла 

родительского 

процесса 

Таблица 

дескрипторов 

файла 

дочернего 

процесса 

Таблица 

дескрипторов 

файла 

постороннего 

процесса 


Таблица 

открытого файла 


1-узел 



косвенный 

блок Однократный 
косвенный 
блок 


Рис. 10.18. Связь между таблицей дескрипторов файлов, 
таблицей открытых файлов и таблицей і-узлов 

Однако если какой-нибудь посторонний процесс откроет файл, он получит 
свою собственную запись в таблице открытых файлов со своей позицией в файле, 
что как раз и нужно. Таким образом, задача таблицы открытых файлов заключа¬ 
ется в том, чтобы позволить родительскому и дочернему процессам совместно 
использовать один указатель в файле, но для посторонних процессов выделять 
отдельные указатели. 11 
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Итак, мы показали, как работающие процессы получают доступ к позиции в 
файле и к і-узлу файла, і-узел содержит дисковые адреса первых 10 блоков файла. 
Если позиция в файле попадает в его первые 10 блоков, то считывается нужный 
блок файла, а данные копируются пользователю. Для поддержки файлов, длина 
которых превышает 10 блоков, в і-узле содержится дисковый адрес одинарного 
косвенного блока (см. рис. 10.18). Этот блок содержит дисковые адреса дополни¬ 
тельных блоков файла. Например, если размер блока составляет 1 Кбайт, а диско¬ 
вый адрес занимает 4 байт, то одинарный косвенный блок может хранить до 256 дис¬ 
ковых адресов. Такая схема позволяет поддержать файлы размером до 266 Кбайт. 

Для файлов, размер которых превосходит 266 Кбайт, используется двойной 
косвенный блок. Он содержит адреса 256 одинарных косвенных блоков, каждый 
из которых содержит адреса 256 блоков данных. Такая схема позволяет поддер¬ 
жать файлы размером до 10 + 2 16 блоков (67 119 104 байт). Если и этого оказыва¬ 
ется недостаточно, в і-узле есть место для тройного косвенного блока. Его указа¬ 
тели показывают на 256 двойных косвенных блоков. 

Файловая система Вегкеіеу Раз* 

Приведенное выше описание объясняет принципы работы классической файло¬ 
вой системы ІЖІХ. Теперь познакомимся с усовершенствованиями этой системы, 
реализованными в версии Вегкеіеу. Во-первых, были реорганизованы каталоги. 
Длина имен файлов была увеличена до 255 символов. Конечно, изменение.струк¬ 
туры всех каталогов означало, что программы, продолжающие наивно читать на¬ 
прямую содержимое каталогов (что было и остается допустимым) и ожидающие 
обнаружить в них последовательность 16-байтовых записей, более не работали. 
Для обеспечения совместимости двух систем в системе Вегкеіеу были разработа¬ 
ны системные вызовы орепсіі г, сіозесііг, геасісііг и геѵѵі псісіі г, чтобы программы мог¬ 
ли читать каталоги, не зная их внутренней структуры. Позднее длинные имена 
файлов и эти системные вызовы были добавлены ко всем другим версиям ИМІХ и 
к стандарту Р05ІХ. 

Структура каталогов В5Б, поддерживающая имена файлов длиной до 255 сим¬ 
волов, показана на рис. 10.19. Каждый каталог состоит из некоторого целого коли¬ 
чества дисковых блоков, так что каталоги могут записываться на диск как единое 
целое. Внутри каталога записи файлов и каталогов никак не отсортированы, при 
этом каждая запись сразу следует за предыдущей записью. В конце каждого блока 
может оказаться несколько неиспользованных байтов, так как записи могут быть 
различного размера. 

Каждая каталоговая запись на рис. 10.19 состоит из четырех полей фиксиро¬ 
ванной длины и одного поля переменной длины. Первое поле представляет собой 
номер і-узла, равный 19 для файла соіоззаі, 42 для файла ѵоіитіпоиз и 88 для катало¬ 
га Ъщсііг. Следом за номером і-узла идет поле, сообщающее размер всей каталоговой 
записи в байтах, возможно, вместе с дополнительными байтами-заполнителями 
в конце записи. Это поле необходимо, чтобы найти следующую запись. На рисунке 
это поле обозначено стрелкой, указывающей на начало следующей записи. Затем 
располагается поле типа файла, определяющее, является ли этот файл каталогом 
и т. д. Последнее поле содержит длину имени файла в байтах (8, 10 и 6 для данного 
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примера). Наконец, идет само имя файла, заканчивающееся нулевым байтом и 
дополненное до 32-битовой границы. За ним могут следовать дополнительные бай¬ 
ты-заполнители. 




Рис. 10.19. Каталог В50 стремя файлами (а); тот же каталог после удаления файла 

ѵоіитіпоиз (б) 


На рис. 10.19, б показан тот же самый каталог после того, как файл ѵоіитіпоиз 
был удален. Все, что при этом делается в каталоге, — увеличивается размер запи¬ 
си предыдущего файла соіоззаі, а байты каталоговой записи удаленного файла 
ѵоіитіпоиз превращаются в заполнители первой записи. Впоследствии эти байты 
могут использоваться для записи при создании нового файла. 

Поскольку поиск в каталогах производится линейно, он может занять много 
времени, пока не будет найдена запись у конца большого каталога. Для увеличе¬ 
ния производительности в В5Б было добавлено кэширование имен. Прежде чем 
искать имя в каталоге, система проверяет кэш. Если имя файла есть в кэше, то 
в каталоге его уже можно не искать. 

Вторым существенным изменением, введенным в Вегкеіеу, было разбиение 
диска на группы цилиндров, у каждой из которых был собственный суперблок, 
і-узлы и блоки данных. Идея такой организации диска заключается в том, чтобы 
хранить і-узел и блоки данных файла ближе друг к другу. Тогда при обращении к 
файлам снижается время, затрачиваемое жестким диском на перемещение блоков 
головок. По мере возможности блоки для файла выделяются в группе цилиндров, 
в которой содержится і-узел. 

Третье изменение заключалось в использовании блоков не одного, а двух раз¬ 
меров. Для хранения больших файлов значительно эффективнее использовать 
небольшое количество крупных блоков, чем много маленьких блоков. С другой 
стороны, размер многих файлов в системе ЕДПХ невелик, поэтому при использо¬ 
вании только блоков большого размера расходовалось бы слишком много диско- 
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вого пространства. Наличие блоков двух размеров обеспечивает эффективное чте¬ 
ние/запись для больших файлов и эффективное использование дискового про¬ 
странства для небольших файлов. Платой за эффективность является значитель¬ 
ная дополнительная сложность программы. 

Файловая система Ыпих 

Изначально в операционной системе Ыпих использовалась файловая система опе¬ 
рационной системы МШІХ. Однако в системе МШІХ длина имен файлов ограни¬ 
чивалась 14 символами (для совместимости с ІШІХ Ѵег5Іоп7), а максимальный 
размер файла был равен 64 Мбайт. Поэтому у разработчиков операционной систе¬ 
мы Ыпих практически сразу появился интерес к усовершенствованию файловой 
системы. Первым шагом вперед стала файловая система Ехі, в которой длина имен 
файлов была увеличена до 255 символов, а размер файлов — до 2 Гбайт. Однако 
эта система была медленнее файловой системы МШІХ, поэтому исследования не¬ 
которое время продолжались. Наконец, была разработана файловая система Ехі2, 
с длинными именами файлов, длинными файлами и высокой производительностью. 
Эта файловая система и стала основной файловой системой Ыпих. Однако опера¬ 
ционная система Ыпих также поддерживает еще более десятка файловых систем, 
используя для этого файловую систему ИЕЗ (описанную в следующем разделе). 
При компоновке операционной системы Ыпих предлагается сделать выбор файло¬ 
вой системы, которая будет встроена в ядро. Другие файловые системы при необхо¬ 
димости могут динамически подгружаться во время исполнения в виде модулей. 

Файловая система Ехі2 очень похожа на файловую систему Вегкеіеу Раз! Еііе 
зузГет с небольшими изменениями. Размещение файловой системы Ехі2 на жест¬ 
ком диске показано на рис. 10.20. Вместо того чтобы использовать группы цилин¬ 
дров, что практически ничего не значит при современных дисках с виртуальной 
геометрией, она делит диск на группы блоков, независимо от того, где располага¬ 
ются границы между цилиндрами. Каждая группа блоков начинается с суперблока, 
в котором хранится информация о том, сколько блоков и і-узлов находятся в дан¬ 
ной группе, о размере группы блоков и т. д. Затем следует описатель группы, содер¬ 
жащий информацию о расположении битовых массивов, количестве свободных 
блоков и і-узлов в группе, а также количестве каталогов в группе. Эта информация 
важна, так как файловая система Ехі2 пытается распространить каталоги равномер¬ 
но по всему диску. 
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блоков 1 
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Рис. 10.20. Размещение файловой системы Ех12 на диске 

В двух битовых массивах ведется учет свободных блоков и свободных і-узлов. 
Размер каждого битового массива равен одному блоку. При размере блоков в 1 Кбайт 
такая схема ограничивает размер группы блоков 8192 блоками и 8192 і-узлами. 
(На практике ограничение числа і-узлов никогда не встречается, так как блоки 
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заканчиваются раньше.) Затем располагаются сами і-узлы. Размер каждого і-узла — 
128 байт, что в два раза больше размера стандартных і-узлов в ІЛЧІХ (см. табл. 10.13). 
Дополнительные байты в і-узле используются следующим образом. Вместо 10 пря¬ 
мых и 3 косвенных дисковых адресов файловая система Ьіпих позволяет 12 пря¬ 
мых и 3 косвенных дисковых адреса. Кроме того, длина адресов увеличена с 3 до 
4 байт, и это позволяет поддерживать дисковые разделы размером более 2 24 бло¬ 
ков (16 Гбайт), что уже стало проблемой для ІЛЧІХ. Помимо этого зарезервирова¬ 
ны поля для указателей на списки управления доступом, что должно обеспечить 
более высокую степень защиты, но это пока находится на стадии проектирования. 
Остаток і-узла зарезервирован на будущее. Как показывает история, неиспользуе¬ 
мые биты недолго остаются таковыми. 

Работа файловой системы похожа на функционирование быстрой файловой 
системы Вегкеіеу. Однако в отличие от В5Б, в системе Ілпих используются дис¬ 
ковые блоки только одного размера, 1 Кбайт. Быстрая файловая система Вегкеіеу 
использует 8-килобайтные блоки, которые затем разбиваются при необходимости 
на килобайтные фрагменты. Файловая система Ехі2 делает примерно то же самое, 
но более простым способом. Как и система Вегкеіеу, когда файл увеличивается в 
размерах, файловая система Ехі2 пытается поместить новый блок файла в ту же 
группу блоков, что и остальные блоки, желательно сразу после предыдущих бло¬ 
ков. Кроме того, при создании нового файла в каталоге файловая система Ехі2 ста¬ 
рается выделить ему блоки в той же группе блоков, в которой располагается ката¬ 
лог. Новые каталоги, наоборот, равномерно распределяются по всему диску. 

Другой файловой системой Ьіпих является файловая система /ргос (ргосезз — 
процесс). Идея этой файловой системы изначально была реализована в 8-й редак¬ 
ции операционной системы ІЛЧІХ, созданной лабораторией Веіі ЬаЬз, а позднее 
скопированной в 4.4В5В и Зузіеш V. Однако в операционной системе Ьіпих дан¬ 
ная идея получила дальнейшее развитие. Основная концепция этой файловой 
системы заключается в том, что для каждого процесса системы создается подката¬ 
лог в каталоге /ргос. Имя подкаталога формируется из РШ процесса в десятичном 
формате. Например, /ргос619 — это каталог, соответствующий процессу с РШ 619. 
В этом каталоге располагаются файлы, которые хранят информацию о процессе — 
его командную строку, строки окружения и маски сигналов. В действительности 
этих файлов на диске нет. Когда они считываются, система получает информацию 
от фактического процесса и возвращает ее в стандартном формате. 

Многие расширения, реализованные в операционной системе Ьіпих, относятся к 
файлам и каталогам, расположенным в каталоге /ргос. Они содержат информацию 
о центральном процессоре, дисковых разделах, векторах прерывания, счетчиках ядра, 
файловых системах, подгружаемых модулях и о многом другом. Непривилегирован¬ 
ные программы пользователя могут читать большую часть этой информации, что 
позволяет им узнать о поведении системы безопасным способом. Некоторые из этих 
файлов могут записываться в каталог /ргос, чтобы изменить параметры системы. 


Файловая система ЫР5 

Сети играют главную роль в операционной системе ІЛЧІХ с самого начала (пер¬ 
вая сеть в системе ІЛЧІХ была построена для переноса нового ядра с машины 
РБР-11 /70 на компьютер Іпіегйаіа 8/32). В данном разделе мы рассмотрим фай- 
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ловую систему ІЧР8 (ЫеІ\\ г огк Рііе Зузіет — сетевая файловая система) корпо¬ 
рации 5ип Місгозузіетз, использующуюся на всех современных системах ІЛЧІХ 
(а также на некоторых не-ІЛЧІХ системах) для объединения на логическом уров¬ 
не файловых систем отдельных компьютеров в единое целое. Интересны три 
аспекта файловой системы ИР5: архитектура, протокол и реализация. Мы рассмот¬ 
рим их все по очереди. 

Архитектура файловой системы ЫР5 

В основе файловой системы ИР5 лежит представление о том, что пользоваться 
общей файловой системой может произвольный набор клиентов и серверов. Во мно¬ 
гих случаях все клиенты и серверы располагаются на одной и той же локальной 
сети, хотя этого не требуется. Файловая система ИР5 может также работать в гло¬ 
бальной сети, если сервер находится далеко от клиента. Для простоты мы будем 
говорить о клиентах и серверах, как если бы они работали на различных компью¬ 
терах, хотя файловая система №5 позволяет каждой машине одновременно быть 
клиентом и сервером. 

Каждый сервер файловой системы ОТЗ экспортирует один или несколько ее 
каталогов, предоставляя доступ к ним удаленным клиентам. Как правило, доступ 
к каталогу предоставляется вместе со всеми его подкаталогами, то есть все дерево 
каталогов экспортируется как единое целое. Список экспортируемых сервером 
каталогов хранится в файле /еіс/ехрогСз, таким образом, эти каталоги экспортиру¬ 
ются автоматически при загрузке сервера. Клиенты получают доступ к экспорти¬ 
руемым каталогам, монтируя эти каталоги. Когда клиент монтирует (удаленный) 
каталог, этот каталог становится частью иерархии каталогов клиента, как показа¬ 
но на рис. 10.21. (Каталоги показаны на рисунке в виде квадратов, а файлы — в виде 
кружков.) 


Клиент 1 




- Монтирование 



Рис. 10.21. Примеры монтирования удаленных файловых систем 




820 


Глава 10. Рассмотрение конкретных случаев: ЦЫІХ и Упих 


В этом примере клиент 1 смонтировал каталог Ып сервера 1 в своем собствен¬ 
ном каталоге Ып , поэтому он теперь может обращаться к оболочке сервера 1 как к 
Ып/зк. У бездисковых рабочих станций часто есть только скелет файловой систе¬ 
мы (в ОЗУ), а все свои файлы они получают с удаленных серверов, как в данном 
примере. Аналогично клиент 1 смонтировал каталог рго/есіз сервера 1 в своем ка¬ 
талоге изг/азі/тогк , поэтому он теперь может получать доступ к файлу а как к изг/ 
азі/шогк/рюіі/а. Как видно из этого примера, у одного и того же файла могут быть 
различные имена на различных клиентах, так как их каталоги могут монтироваться 
в различных узлах каталоговых деревьев. Выбор узла, в котором монтируется уда¬ 
ленный каталог, целиком зависит от клиента. Сервер не знает, где клиент монти¬ 
рует его каталог. 

Протоколы файловой системы N^3 

Так как одна из целей файловой системы ИР5 заключается в поддержке разнород¬ 
ных систем, в которых клиенты и серверы могут работать под управлением раз¬ 
личных операционных систем и на различном оборудовании, существенно, чтобы 
интерфейс между клиентами и серверами был тщательно определен. Только в этом 
случае можно ожидать, что новый написанный клиент будет корректно работать 
с существующими серверами, и наоборот. 

В файловой системе ИР5 эта задача выполняется при помощи двух протоко¬ 
лов клиент-сервер. Протокол — это набор запросов, посылаемых клиентами сер¬ 
верам, и ответов серверов, посылаемых клиентам. 

Первый протокол ИР5 управляет монтированием каталогов. Клиент может 
послать серверу путь к каталогу и запросить разрешение смонтировать этот каталог 
где-либо в своей иерархии каталогов. Данные о месте, в котором клиент намерева¬ 
ется смонтировать удаленный каталог, серверу не посылаются, так как серверу это 
безразлично. Если путь указан верно и указанный каталог был экспортирован, 
тогда сервер возвращает клиенту дескриптор файла, содержащий поля, однознач¬ 
но идентифицирующие тип файловой системы, диск, і-узел каталога и информа¬ 
цию о правах доступа. Этот дескриптор файла используется последующими обра¬ 
щениями чтения и записи к файлам в монтированном каталоге или в любом из его 
подкаталогов. 

Во время загрузки операционная система ІЛЧІХ, прежде чем перейти в много¬ 
пользовательский режим, запускает сценарий оболочки /еіс/гс. В этом сценарии 
можно разместить команды монтировки файловых систем. Таким образом, все 
необходимые удаленные файловые системы будут автоматически смонтированы 
прежде, чем будет разрешена регистрация в системе. В качестве альтернативы в 
большинстве версий системы ІІМІХ также поддерживается автомонтировка. Это 
свойство позволяет ассоциировать с локальным каталогом несколько удаленных 
каталогов. Ни один из этих удаленных каталогов не монтируется во время загруз¬ 
ки операционной системы (не происходит даже контакта с сервером). Вместо это¬ 
го при первом обращении к удаленному файлу (когда файл открывается) опера¬ 
ционная система посылает каждому серверу сообщение. Побеждает ответивший 
первым сервер, чей каталог и монтируется. 

У автомонтировки есть два принципиальных преимущества перед статической 
монтировкой с использованием файла /еіс/гс. Во-первых, если один из серверов, 
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перечисленных в файле /еіс/гс, окажется выключенным, запустить клиента будет 
невозможно, по крайней мере без определенных трудностей, задержки и большого 
количества сообщений об ошибках. Если пользователю в данный момент этот сервер 
не нужен, вся работа просто окажется напрасной. Во-вторых, предоставление кли¬ 
енту возможности связаться с несколькими серверами параллельно позволяет зна¬ 
чительно повысить устойчивость системы к сбоям (так как для работы достаточно 
всего одного работающего сервера) и улучшить показатели производительности (так 
как первый ответивший сервер скорее всего окажется наименее загруженным). 

С другой стороны, при таком подходе неявно подразумевается, что все указан¬ 
ные как альтернативные файловые системы идентичны для автомонтировки. Так 
как файловая система ЫР5 не предоставляет поддержки репликации файлов или 
каталогов, то следить за идентичностью всех файловых систем должен сам пользо¬ 
ватель. Поэтому автомонтировка, как правило, используется для файловых сис¬ 
тем, в которых клиенту разрешено только чтение. Такие файловые системы обыч¬ 
но содержат системные двоичные файлы, а также другие редко изменяемые файлы. 

Второй протокол ИР5 предназначен для доступа к каталогам и файлам. Клиен¬ 
ты могут посылать серверам сообщения, содержащие команды управления ката¬ 
логами и файлами, что позволяет им создавать, удалять, читать и писать файлы. 
Кроме того, у клиентов есть доступ к атрибутам файла, таким как режим, размер 
и время последнего изменения файла. Файловой системой ИР5 поддерживается 
большинство системных вызовов операционной системы ІШІХ, за исключением, 
как ни странно, системных вызовов ореп и сіозе. 

Пропуск системных вызовов ореп и сіозе не случаен. Это сделано намеренно. 
Нет необходимости открывать файл, прежде чем прочитать его. Также не нужно 
закрывать файл после того, как данные из него прочитаны. Вместо этого, чтобы 
прочитать файл, клиент посылает на сервер сообщение Іоокир, содержащее имя 
файла, с запросом найти этот файл и вернуть дескриптор файла, представляющий 
собой структуру, идентифицирующую файл (то есть содержащую идентификатор 
файловой системы и номер і-узла вместе с прочей информацией). В отличие от 
системного вызова ореп, операция Іоокир не копирует никакой информации во 
внутренние системные таблицы. Системному вызову геасі подается на входе деск¬ 
риптор файла, который предстоит прочитать, смещение в файле, а также количе¬ 
ство байтов, которые нужно прочитать. Таким образом, каждое сообщение явля¬ 
ется самодостаточным. Преимущество такой схемы заключается в том, что серверу 
не нужно помнить что-либо об открытых соединениях между обращениями к нему. 
Поэтому если на сервере произойдет сбой с последующей перезагрузкой, не будет 
потеряно никакой информации об открытых файлах, так как терять просто нече¬ 
го. Такие серверы называются серверами без состояния. 

К сожалению, метод файловой системы ИР5 усложняет достижение точной 
файловой семантики системы ІЖІХ. Например, в операционной системе ІЖІХ 
файл может быть открыт и заблокирован, так что никакой другой процесс не смог 
получить к этому файлу доступ. Когда файл закрывается, все его блокировки сни¬ 
маются. В сервере без состояния, как в файловой системе ИР5, с открытыми фай¬ 
лами нельзя связать блокировку, так как сервер не знает, какие файлы открыты. 
Следовательно, в файловой системе ИР5 требуется отдельный специальный ме¬ 
ханизм осуществления блокировки. 




822 


Глава 10. Рассмотрение конкретных случаев: ІІЫІХи Ыпих 


Файловая система ИР5 использует стандартный механизм защиты ІІШХ с би¬ 
тами пюх для владельца, группы и всех прочих пользователей (этот вопрос упоми¬ 
нался в главах 1 и 6, а также подробно обсуждается ниже). Изначально каждое со¬ 
общение с запросом просто содержало идентификаторы пользователя и группы 
вызывающего процесса, которые сервер ИР5 использовал для проверки прав до¬ 
ступа. Сервер ИР5 предполагал, что клиенты не будут его обманывать. Несколько 
лет опыта работы с файловой системой ИР5 показали, что такое предположение 
было (как бы это помягче назвать?) наивным. Сегодня для установки надежного 
ключа для аутентификации клиента и сервера при каждом запросе и каждом отве¬ 
те можно использовать шифрование с открытым ключом. При этом злоумышлен¬ 
ник не сможет выдать себя за другого клиента (или другой сервер), так как ему 
неизвестен секретный ключ этого клиента (или сервера). 

Реализация файловой системы ЫР5 

Хотя реализация программ клиента и сервера не зависит от протоколов ХР5, в боль¬ 
шинстве систем ІЖІХ используется трехуровневая реализация, сходная с изобра¬ 
женной на рис. 10.22. Верхний уровень представляет собой уровень системных 
вызовов. Он управляет такими системными вызовами, как ореп, геасі и сіозе. После 
анализа системного вызова и проверки его параметров он вызывает второй уровень, 
уровень ѴР5 (Ѵігіиаі Рііе 5уз1еш — виртуальная файловая система). 


Ядро клиента Ядро сервера 



Рис. 10.22. Структура уровней файловой системы ІУРЗ 


Задача уровня ѴР5 заключается в управлении таблицей, содержащей по одной 
записи для каждого открытого файла, аналогичной таблице і-узлов для открытых 
файлов в системе ІЖІХ. В обычной системе ІЖІХ і-узел однозначно указывается 
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парой (устройство, номер і-узла). Вместо этого уровень ѴР5 содержит для каждо¬ 
го открытого файла записи, называемые ѵ-узлами (ѵігСпаІ і-посіе — виртуальный 
і-узел). Ѵ-узлы используются, чтобы отличать локальные файлы от удаленных. 
Для удаленных файлов предоставляется информация, достаточная для доступа к 
ним. Для локальных файлов записываются сведения о файловой системе и і-узле, 
так как современные системы ІЖІХ могут поддерживать несколько файловых 
систем (например, Ѵ7, Вегкеіеу РР5, ехі21з, /ргос, РАТ и т. д.). Хотя уровень ѴР5 
был создан для поддержки файловой системы ЫР5, сегодня он поддерживается 
большинством современных систем ІЖІХ как составная часть операционной сис¬ 
темы, даже если ЫР5 не используется. 

Чтобы понять, как используются ѵ-узлы, рассмотрим выполнение последова¬ 
тельности системных вызовов шоипі, ореп и геаф Чтобы смонтировать файловую 
систему, системный администратор (или сценарий / еіс/гс ) вызывает программу 
тоипі, указывая ей удаленный каталог, локальный каталог, в котором следует 
смонтировать удаленный каталог, и прочую информацию. Программа тоипі ана¬ 
лизирует имя удаленного каталога и обнаруживает имя сервера ЫР5, на котором 
располагается удаленный каталог. Затем она соединяется с этой машиной, запра¬ 
шивая у нее дескриптор удаленного каталога. Если этот каталог существует и его 
удаленное монтирование разрешено, сервер возвращает его дескриптор. Наконец, 
программа тоипі обращается к системному вызову шоипѣ, передавая ядру получен¬ 
ный от сервера дескриптор каталога. 

Затем ядро формирует для удаленного каталога ѵ-узел и просит программу 
клиента ИРЗ на рис. 10.22 создать в своих внутренних таблицах г-узел (удален¬ 
ный і-узел) для хранения дескриптора файла. Ѵ-узел указывает на г-узел. Каждый 
ѵ-узел на уровне ѴР5 будет в конечном итоге содержать либо указатель на г-узел 
в программе клиента ИР5, либо указатель на і-узел в одной из локальных файловых 
систем (показанный на рис. 10.22 в виде штриховой линии). По содержимому ѵ-узла 
можно понять, является ли файл или каталог локальным или удаленным. Если он 
локальный, то может быть найдена соответствующая файловая система и і-узел. 
Если файл удаленный, может быть найден удаленный хост и дескриптор файла. 

Когда на клиенте открывается удаленный файл, при анализе пути файла ядро 
обнаруживает каталог, в котором смонтирована удаленная файловая система. Оно 
видит, что этот каталог удаленный, а в ѵ-узле каталога находит указатель на г-узел. 
Затем она просит программу клиента ЫР5 открыть файл. Программа клиента ХР5 
просматривает оставшуюся часть пути на удаленном сервере, ассоциированном 
с монтированным каталогом, и получает обратно дескриптор файла для него. 
Он создает в своих таблицах г-узел для удаленного файла и докладывает об этом 
уровню ѴЕ5, который помещает в свои таблицы ѵ-узел для файла, указывающий 
на г-узел. Мы видим, что и в этом случае у каждого открытого файла или каталога 
есть ѵ-узел, указывающий на г-узел или і-узел. 

Вызывающему процессу выдается дескриптор удаленного файла. Этот дескрип¬ 
тор файла отображается на ѵ-узел при помощи таблиц уровня ѴЕ5. Обратите вни¬ 
мание, что на сервере не создается никаких записей в таблицах. Хотя сервер готов 
предоставить дескрипторы файлов по запросу, он не следит за состоянием дескрип¬ 
торов файлов. Когда дескриптор файла присылается серверу для доступа к файлу, 
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сервер проверяет дескриптор и использует его, если дескриптор действителен. При 
проверке может проверяться ключ аутентификации, содержащийся в заголовках 
вызова удаленной процедуры К.РС. 

Когда дескриптор файла используется в последующем системном вызове, на¬ 
пример геасі, уровень ѴР5 находит соответствующий ѵ-узел и по нему определяет, 
является ли он локальным или удаленным, а также какой і-узел или г-узел его опи¬ 
сывает. Затем он посылает серверу сообщение, содержащее дескриптор, смещение 
в файле (хранящееся на стороне клиента, а не сервера) и количество байтов. Для 
повышения эффективности обмен информацией между клиентом и сервером вы¬ 
полняется большими порциями, как правило, по 8192 байт, даже если запрашива¬ 
ется меньшее количество байтов. 

Когда сообщение с запросом прибывает на сервер, оно передается там уровню 
ѴР5, который определяет файловую систему, содержащую файл. Затем уровень 
ѴР5 обращается к этой файловой системе, чтобы прочитать и вернуть байты. Эти 
данные передаются клиенту. После того как уровень ѴР5 клиента получает 8-ки- 
лобайтную порцию данных, которую запрашивал, он автоматически посылает за¬ 
прос на следующую порцию, чтобы она была под рукой, когда понадобится. Такая 
функция, называемая опережающим чтением, позволяет значительно увеличить 
производительность. 

При записи в удаленный файл проходится аналогичный путь от клиента к 
серверу. Данные также передаются 8-килобайтными порциями. Если системному 
вызову мгИе подается менее 8 Кбайт данных, данные просто накапливаются ло¬ 
кально. Только когда порция в 8 Кбайт готова, она посылается серверу. Если файл 
закрывается, то весь остаток немедленно посылается серверу. 

Кроме того, для увеличения производительности применяется кэширование, 
как в обычной системе ІЖІХ. Серверы кэшируют данные, чтобы снизить количе¬ 
ство обращений к дискам, но это происходит незаметно для клиентов. Клиенты 
управляют двумя кэшами, одним для атрибутов файлов (і-узлов) и одним для дан¬ 
ных. Когда требуется либо і-узел, либо блок файла, проверяется, нельзя ли полу¬ 
чить эту информацию из кэша. Если да, то обращения к сети можно избежать. 

Хотя кэширование на стороне клиента во много раз повышает производитель¬ 
ность, оно также приводит к появлению новых непростых проблем. Предположим, 
что два клиента сохранили в своих кэшах один и тот же блок файла и что один из 
них его модифицировал. Когда другой клиент считывает этот блок, он получает из 
кэша старое значение блока. 

Учитывая серьезность данной проблемы, реализация ЫЕ5 пытается смягчить 
ее остроту несколькими способами. Во-первых, с каждым блоком кэша ассоцииро¬ 
ван таймер. Когда время истекает, запись считается недействительной. Как прави¬ 
ло, для блоков с данными таймер устанавливается на 3 с, а для блоков каталога — 
30 с. Таким образом, риск несколько снижается. Кроме того, при каждом открытии 
кэшированного файла серверу посылается сообщение, чтобы определить, когда 
в последний раз был модифицирован этот файл. Если последнее изменение про¬ 
изошло после того, как была сохранена в кэше локальная копия файла, эта копия 
из кэша удаляется, а с сервера получается новая копия. Наконец, каждые 30 с ис¬ 
текает время таймера, и все «грязные» (модифицированные) блоки кэша посыла- 
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ются на сервер. Хотя такая схема и далека от совершенства, подобные «заплатки» 
позволяют пользоваться этой системой в большинстве практических случаев. 


Безопасность в ІШІХ 

Несмотря на свое название, операционная система ІЖІХ была с самого начала 
многопользовательской системой. Это значит, что безопасность и контроль над 
информацией были встроены в систему с момента ее создания. В следующих разде¬ 
лах мы рассмотрим некоторые аспекты безопасности в операционной системе ІЖІХ. 


Основные понятия 

Сообщество пользователей операционной системы ІЖІХ состоит из некоторого 
количества зарегистрированных пользователей, у каждого из которых есть свой 
уникальный ІІШ (ІІвег Ш — идентификатор пользователя). ІІШ представляет 
собой целое число в пределах от 0 до 65 535. Идентификатором владельца помеча¬ 
ются файлы, процессы и другие ресурсы. По умолчанию владельцем файла явля¬ 
ется пользователь, создавший этот файл, хотя владельца можно сменить. 

Пользователи могут организовываться в группы, которые также нумеруются 
16-разрядными целыми числами, называемыми СГО (Сгоир ГО — идентификатор 
группы). Назначение пользователя к группе выполняется вручную системным 
администратором и заключается в создании нескольких записей в системной базе 
данных, в которой содержится информация о том, какой пользователь к какой 
группе принадлежит. Вначале пользователь мог принадлежать только к одной 
группе, но теперь в некоторых версиях системы ІЖІХ пользователь может одно¬ 
временно принадлежать к нескольким группам. Чтобы не усложнять вопрос, мы 
более не станем обсуждать эту возможность. 

Основной механизм безопасности в операционной системе ІЖІХ прост. Каж¬ 
дый процесс несет на себе ІІГО и СГО своего владельца. Когда создается файл, он 
получает ІІГО и СГО создающего его процесса. Файл также получает набор разре¬ 
шений доступа, определяемых создающим процессом. Эти разрешения определя¬ 
ют доступ к этому файлу для владельца файла, для других членов группы владель¬ 
ца файла и для всех прочих пользователей. Для каждой из этих трех категорий 
определяется три вида доступа: чтение, запись и исполнение файла, что обознача¬ 
ется соответственно буквами г,т их ( геасі , тгііе, ехесиіе). Возможность исполнять 
файл, конечно, имеет смысл только в том случае, если этот файл является испол¬ 
няемой двоичной 1 программой. Попытка запустить файл, у которого есть разре¬ 
шение на исполнение, но который не является исполняемым (то есть не начинает¬ 
ся с соответствующего заголовка), закончится ошибкой. Поскольку существует три 
категории пользователей и три вида доступа для каждой категории, все режимы 
доступа к файлу можно закодировать 9 битами. Некоторые примеры этих 9-раз- 
рядных чисел и их значения показаны в табл. 10.14. 


1 Для возможности запуска сценария оболочки, представляющего собой, по сути, не двоичный, а тек¬ 
стовый файл, у этого файла также нужно установить командой сктоН биты г их, — Примеч. перев. 
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Таблица 10 . 14 . Некоторые примеры режимов защиты файлов 


Двоичное Символьное Разрешенный доступ 


111000000 

ГѴѴХ . 

111111000 

ГѴѴХГѴѴХ--- 

110100000 

гѵѵ-г . 

110100100 

гѵѵ-г—г— 

111101101 

гѵѵхг-хг-х 

000000000 


000000111 

.ГѴѴХ 


Владелец может читать, писать и исполнять 
Владелец и группа могут читать, писать и исполнять 
Владелец может читать и писать, группа может читать 
Владелец может читать и писать, все остальные могут читать 
Владелец имеет все права, все остальные могут читать и исполнять 
Н и у кого нет доступа 

Только у посторонних есть доступ (странно, но законно) 


Первые два примера в таблице понятны. В них к файлу предоставляется пол¬ 
ный доступ для владельца файла и для его группы соответственно. В третьем при¬ 
мере группе владельца разрешается читать файл, но не разрешается его изменять, 
а всем посторонним запрещается всякий доступ. Вариант из четвертого примера 
часто применяется в тех случаях, когда владелец файла желает сделать файл с дан¬ 
ными публичным. Пятый пример показывает режим защиты файла, представляю¬ 
щего собой опубликованную программу. В шестом примере доступ запрещен всем. 
Такой режим иногда используется для файлов-пустышек, применяемых для реа¬ 
лизации взаимных исключений, так как любая попытка создания такого файла 
приведет к ошибке, если такой файл уже существует. Если несколько программ 
одновременно попытаются создать такой файл в качестве блокировки, только 
первой из них это удастся. Режим, показанный в последнем примере, довольно 
странный, так как он предоставляет всем посторонним пользователям больше 
привилегий, чем владельцу файла. Тем не менее такой режим допустим. К счас¬ 
тью, у владельца файла всегда есть способ изменить в дальнейшем режим доступа 
к файлу, даже если ему будет запрещен всякий доступ к самому файлу. 

Пользователь, ШБ которого равен 0, является особым пользователем и назы¬ 
вается суперпользователем (зирешзег или гооі). Суперпользователь может читать 
и писать все файлы в системе, независимо от того, кто ими владеет и как они 
защищены. Процессы с ЕІШ = 0 также обладают возможностью обращаться к не¬ 
большой группе системных вызовов, доступ к которым запрещен для обычных 
пользователей. Как правило, пароль суперпользователя известен только систем¬ 
ному администратору, хотя многие студенты младших курсов смотрят на поиск 
дыр в системе безопасности, которые должны позволить им регистрироваться 
в системе в качестве суперпользователя, как на увлекательный спорт. Руководство 
компьютерных центров обычно недовольно такого рода активностью. 

Каталоги представляют собой файлы и обладают теми же самыми режимами 
защиты, что и обычные файлы. Отличие состоит в том, что бит х интерпретиру¬ 
ется в отношении каталогов как разрешение не исполнения, а поиска в каталоге. 
Таким образом, каталог с режимом пахг-хг-х позволяет своему владельцу читать, 
изменять каталог, а также искать в нем файлы, а всем остальным пользователям 
разрешает только читать каталоги и искать файлы в них, но не создавать в них но¬ 
вые файлы или удалять файлы из этого каталога. 

У специальных файлов, соответствующих устройствам ввода-вывода, есть 
те же самые биты защиты. Благодаря этому может использоваться тот же самый 
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механизм для ограничения доступа к устройствам ввода-вывода. Например, вла¬ 
дельцем специального файла принтера /сіеѵ/ір может быть суперпользователь 
(гооі) или специальный пользователь, демон принтера. При этом режим доступа к 
файлу может быть установлен равным т> -, чтобы все остальные пользовате¬ 

ли не могли напрямую обращаться к принтеру. В противном случае при одновре¬ 
менной печати на принтере нескольких процессов получится полный хаос. 

Конечно, тот факт, что файлом /сіеѵ/ір владеет демон и этот файл имеет режим 

доступа П 0 - ., означает, что более никто не может выводить данные на принтер. 

Хотя такой способ и позволяет избежать множества неприятностей, однако вре¬ 
мя от времени пользователям бывает необходимо напечатать что-нибудь. В дей¬ 
ствительности существует более общая проблема регулируемого доступа ко всем 
устройствам ввода-вывода и другим системным ресурсам. 

Эта проблема была решена с помощью добавления к перечисленным выше 
9 бит нового бита защиты, бита 5ЕТШБ. Когда выполняется программа с уста¬ 
новленным битом 5ЕТШБ, то запускаемому процессу присваивается не ІІШ вы¬ 
звавшего его пользователя или процесса, а ШБ владельца файла. Когда процесс 
пытается открыть файл, то проверяется его рабочий ШБ, а не ШБ запустившего 
его пользователя. Таким образом, если программой, обращающейся к принтеру, 
будет владеть демон с установленным битом 5ЕТШБ, тогда любой пользователь 
сможет запустить ее и запущенный процесс будет обладать полномочиями демона 
(например, правами доступа к /<іеѵ/1р), но только для запуска этой программы 
(которая может устанавливать задания в очередь на принтер). 

В операционной системе ІШІХ есть множество программ, владельцем которых 
является системный администратор, но у них установлен бит 5ЕТШБ. Например, 
программе раз&тсі, позволяющей пользователям менять свои пароли, требуется 
доступ записи к файлу паролей. Если разрешить изменять этот файл кому угодно, 
то ничего хорошего из этой затеи не получится. Вместо этого есть программа, 
владельцем которой выступает гооі, и у файла этой программы установлен бит 
5ЕТШБ. Хотя у этой программы есть полный доступ к файлу паролей, она изме¬ 
нит только пароль вызывавшего ее пользователя и не затронет остального содер¬ 
жимого файла. 

Помимо бита 5ЕТШБ, есть также еще и бит 5ЕТСІБ, работающий аналогич¬ 
но и временно предоставляющий пользователю рабочий СІБ программы. Однако 
на практике этот бит почти не используется. 


Системные вызовы безопасности в ІЖІХ 

Лишь небольшое число системных вызовов относятся к безопасности. Наиболее 
важные системные вызовы перечислены в табл. 10.15. Чаще всего используется 
системный вызов сйтосі. С его помощью можно изменить режим защиты файла. 
Например, оператор 

5 = сПтосК'Ѵизг/азі/пемдате" . 0755); 

устанавливает для файла пещате режим доступа шхг-хг-х, что позволяет запускать 
эту программу всем пользователям (обратите внимание, что 0755 представляет 
собой восьмеричную константу, что удобно в данном случае, так как биты защиты 
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группируются тройками). Изменять биты защиты могут только владелец файла 
и суперпользователь. 

Таблица 10.15. Некоторые системные вызовы, относящиеся к безопасности 

Системный вызов 

Описание 

5=сИтос1(раІИ, тосіе) 

Изменить режим защиты файла 

5=ассез5(раЩ, тобе) 

Проверить разрешение доступа к файлу, используя 
действительные 11Ю и СЮ 

иіб=деЩіб( ) 

Получить действительный ІІЮ 

иіб=де1еиіб( ) 

Получить рабочий ІІЮ 

діП=деІдісі( ) 

Получить действительный СЮ 

діб=де{едіб() 

Получить рабочий СЮ 

з=сМоѵѵп(раІМ, оѵѵпег, дгоир) 

Изменить владельца и группу 

5=5е1иіс1(иіс1) 

Установить ІІЮ 

5=зеідіс1(діс1) 

Установить СЮ 


Системный вызов ассезз проверяет, будет ли разрешен определенный тип дос¬ 
тупа при заданных ИГО и СГО. Этот системный вызов нужен, чтобы избежать по¬ 
явления брешей в системе безопасности. Он используется в программах с установ¬ 
ленным битом ЗЕТИГО, владельцем которых является гооі. Такие программы 
могут выполнять любые действия, поэтому им иногда бывает необходимо опреде¬ 
лить, уполномочен ли вызвавший их пользователь на выполнение определенных 
действий. Программа не может просто попытаться получить требуемый доступ, так 
как любой доступ ей будет обязательно предоставлен. 

Следующие четыре системных вызова возвращают значения реального и рабо¬ 
чего ИГО и СГО. К последним трем системным вызовам разрешено обращаться 
только суперпользователю. Они изменяют владельца файла, а также ИГО и СГО 
процесса. 

Реализация безопасности в ІЖІХ 

Когда пользователь входит в систему, программа регистрации Іо§іп (которая явля¬ 
ется 5ЕТСГО гооі) запрашивает у пользователя его имя и пароль. Затем она хэши¬ 
рует пароль и ищет его в файле паролей /еіс/раззшй, чтобы определить, соответ¬ 
ствует ли хэш-код содержащимся в нем значениям (сетевые системы работают 
несколько по-иному). Хэширование применяется, чтобы избежать хранения паро¬ 
ля в незашифрованном виде где-либо в системе. Если пароль введен верно, про¬ 
грамма регистрации считывает из файла /еіс/раззтй имя программы оболочки, 
которую любит пользователь. Ей может быть программа зк, но это также может 
быть и другая оболочка, например сзк или кзк. Затем программа регистрации ис¬ 
пользует системные вызовы зеіиісі и зеідісі, чтобы установить для себя ИГО и СГО 
(как мы помним, она была запущена как 5ЕТІІГО гооі). После этого программа 
регистрации открывает клавиатуру для стандартного ввода (файл с дескрипто¬ 
ром 0) и экран для стандартного вывода (файл с дескриптором 1), а также экран 
для вывода стандартного потока сообщений об ошибках (файл с дескриптором 2). 






Резюме 


829 


Наконец, она выполняет оболочку, которую указал пользователь, таким образом, 
завершая свою работу. 

С этого момента начинает работу оболочка с установленными ІІГО и СШ, а так¬ 
же стандартными потоками ввода, вывода и ошибок, настроенными на устройства 
ввода-вывода по умолчанию. Все процессы, которые она запускает при помощи 
системного вызова Іогк (то есть команды, вводимые пользователем с клавиатуры), 
автоматически наследуют ІІШ и СШ оболочки, поэтому у них будет верное зна¬ 
чение владельца и группы. Все файлы, создаваемые этими процессами, также будут 
иметь эти значения. 

Когда любой процесс пытается открыть файл, система сначала проверяет биты 
защиты в і-узле файла для заданных значений рабочих ІІШ и СШ, чтобы опреде¬ 
лить, разрешен ли доступ для данного процесса. Если доступ разрешен, файл от¬ 
крывается и процессу возвращается дескриптор файла. В противном случае файл 
не открывается, а процессу возвращается значение -1. При последующих обраще¬ 
ниях к системным вызовам геасі и мгііе проверка не выполняется. В результате, 
если режим защиты файла изменяется уже после того, как файл открыт, новый 
режим не повлияет на процессы, которые уже успели открыть этот файл. 

В операционной системе Ьіпих защита файлов и ресурсов осуществляется так 
же, как и в ІЖІХ. В системе Ьіпих реализованы все функции защиты системы 
ЫШХ, и нет почти ничего такого в системе Ьіпих в области защиты, чего нет в опе¬ 
рационной системе ІЖІХ. 


Резюме 

Операционная система ШПХ начала свое существование как система разделения 
времени для мини-компьютеров, но теперь она используется на различных маши¬ 
нах от ноутбуков до суперкомпьютеров. В операционной системе ІЖІХ есть три 
интерфейса: оболочка, библиотека С и сами системные вызовы. Оболочка позво¬ 
ляет пользователям вводить команды и исполнять их. Это могут быть простые 
команды, конвейеры или более сложные структуры. Ввод и вывод могут пере¬ 
направляться. В библиотеке С содержатся системные вызовы, а также множество 
расширенных вызовов, например ргіпі / для записи в файлы форматированного 
вывода. Фактический интерфейс системных вызовов состоит всего из приблизи¬ 
тельно 100 вызовов, каждый из которых выполняет только необходимые функции 
и ничего более. 

К ключевым понятиям операционной системы ІЖІХ относятся процесс, модель 
памяти, ввод-вывод и файловая система. Процессы могут создавать дочерние про¬ 
цессы, в результате чего формируются деревья процессов. Для управления про¬ 
цессами в ЫШХ используются две ключевые структуры данных: таблица процес¬ 
сов и структура пользователя. Таблица процессов постоянно находится в памяти, 
а структура пользователя может выгружаться на диск. При создании процесса 
дублируется запись в таблице процессов, а также образ памяти процесса. Для пла¬ 
нирования применяется алгоритм, основанный на приоритетах, отдающий пред¬ 
почтение интерактивным процессам. 
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Модель памяти состоит из трех сегментов для каждого процесса: для текста 
(исполняемого кода), данных и стека. Изначально для управления памятью ис¬ 
пользовался свопинг, но в большинстве современных версий системы ІШІХ для 
этого применяется страничная подкачка. Состояние каждой страницы отслежи¬ 
вается в карте памяти, а страничный демон поддерживает достаточное количество 
свободных страниц при помощи алгоритма часов. 

Доступ к устройствам ввода-вывода осуществляется при помощи специальных 
файлов, у каждого из которых есть старший номер устройства и младший номер 
устройства. Для снижения числа обращений к диску в блочных устройствах вво¬ 
да-вывода применяется буферный кэш. Для управления кэшем используется ал¬ 
горитм ЫШ (ЬеазТ-КесепТІу-ІІзесі — с наиболее давним использованием). Сим¬ 
вольный ввод-вывод может осуществляться в обработанном и необработанном 
режимах. Для дополнительных возможностей символьного ввода-вывода приме¬ 
няются дисциплины линии связи или потоки. 

Файловая система в ІШІХ — иерархическая, с файлами и каталогами. Все диски 
монтируются в единое дерево каталогов, начинающееся в одном корне. Отдельные 
файлы могут быть связаны с любым каталогом дерева. Чтобы пользоваться файлом, 
его нужно сначала открыть. При этом процессу, открывающему файл, возвращает¬ 
ся дескриптор файла, который затем используется при чтении этого файла и запи¬ 
си в файл. Внутри файловая система использует три основные таблицы: таблицу 
дескрипторов файлов, таблицу дескрипторов открытых файлов и таблицу і-узлов. 
Из этих таблиц таблица і-узлов является наиболее важной. В ней содержится ин¬ 
формация, необходимая для управления файлом и позволяющая найти его блоки. 

Защита файлов основывается на регулировании доступа для чтения, записи и 
исполнения, предоставляемого владельцу файла, членам его группы и всем осталь¬ 
ным пользователям. Для каталогов бит исполнения интерпретируется как разре¬ 
шение поиска в каталоге. 


Вопросы 

1. Когда ядро перехватывает системный вызов, как оно определяет, который 
системный вызов ему предстоит выполнить? 

2. Каталог содержит следующие файлы: 


аагсіѵагк 

ІегеТ 

Коаіа 

рогроізе 

ипісогп 

ЬопеІізЬ 

§гипіоп 

ІЛата 

циаскег 

ѵісипа 

саруЬага 

Ьуепа 

МагтоТ 

гаЪЬіТ 

\ѵеазе1 

<ЗІП§0 

іЬех 

МиТЬаТсЬ 

зеаЬогзе 

Уак 

еши 

)е11уІізЬ 

ОзТгісЬ 

Типа 

2еЬи 


Какие файлы будут перечислены командой 
15 [аЬс]*е*? 

3. Что делает следующий конвейер оболочки ІШІХ? 
дгер псі хуг | мс -1 
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4. Напишите конвейер ІЖІХ, печатающий восьмую строку файла г в стандарт¬ 
ный вывод. 

5. Зачем в операционной системе ІЖІХ проводится различие между стандарт¬ 
ным выводом и стандартным потоком ошибок, если по умолчанию обоим 
соответствует терминал? 

6. Пользователь вводит с терминала следующие команды: 

а | Ь | с& 

4 | е | Т& 

Сколько новых процессов будет работать, после того как оболочка обрабо¬ 
тает эти команды? 

7. Когда оболочка ІЖІХ запускает новый процесс, она помещает копии своих 
переменных окружения, например НОМЕ, в стек процесса, чтобы процесс 
мог определить свой рабочий каталог. Если этот процесс в дальнейшем со¬ 
здаст дочерний процесс, получит ли созданный дочерний процесс эти пере¬ 
менные автоматически? 

8. Сколько примерно понадобится времени, чтобы создать дочерний про¬ 
цесс при следующих условиях: размер текста =100 Кбайт, размер данных = 
20 Кбайт, размер стека = 10 Кбайт, размер таблицы процессов = 1 Кбайт, 
структуры пользователя = 5 Кбайт. Обработка эмулированного прерывания 
ядром занимает 1 мс, а компьютер может копировать 32-разрядное слово 
каждые 50 нс. Текстовые сегменты используются совместно. 

9. По мере того как мегабайтные программы становились все более распрост¬ 
раненными, время, затрачиваемое на обработку системного вызова 4огк, рос¬ 
ло пропорционально росту размеров программ. Что еще хуже, почти все это 
время просто терялось понапрасну, так как большинство программ сразу 
после системного вызова 4огк выполняли системный вызов ехес. Чтобы по¬ 
высить производительность, университет в Беркли разработал новый сис¬ 
темный вызов ѵ4огк, в котором, вместо того чтобы создавать для дочернего 
процесса отдельное адресное пространство, адресное пространство использу¬ 
ется дочерним процессом совместно с родительским процессом. Опишите 
ситуацию, в которой неверно работающий дочерний процесс может выпол¬ 
нить действия, делающие семантику системного вызова ѵ4огк принципиаль¬ 
но отличной от семантики системного вызова 4огк. 

10. Если значение параметра СРІІ_иза§е (использование центрального процес¬ 
сора) процесса ІЛЧІХ равно 20, сколько интервалов времени Д Т потребу¬ 
ется, чтобы значение этого параметра уменьшилось до 0, если процесс не 
получает от планировщика управления? Используйте простой алгоритм за¬ 
тухания, приведенный в тексте. 

11. Имеет ли смысл забирать у процесса память, когда процесс переходит в со¬ 
стояние зомби? Почему да или почему нет? 

12. С какой аппаратной концепцией тесно связано понятие сигналов? Приве¬ 
дите два примера использования сигналов. 
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13. Как вы думаете, почему разработчики операционной системы 1ЖІХ запре¬ 
тили процессу посылать сигналы процессам, не входящим в его группу про¬ 
цессов? 

14. Как правило, системный вызов реализуется при помощи команды эмулиро¬ 
ванного прерывания. Может ли для этого на компьютере Репііиш исполь¬ 
зоваться обычный процедурный вызов? Если да, то при каких условиях и 
как? Если нет, то почему? 

15. Какие процессы, как правило, обладают более высоким приоритетом, демо¬ 
ны или интерактивные процессы? 

16. При создании нового процесса ему должен быть присвоен уникальный но¬ 
мер РШ. Достаточно ли для этого хранить в ядре счетчик, увеличивающий¬ 
ся на единицу при создании каждого нового процесса, и использовать этот 
счетчик как новый РГО? Аргументируйте свой ответ. 

17. В таблице процессов для каждого процесса хранится РШ родительского 
процесса. Зачем? 

18. Какая комбинация битов вЬагіп й Да%5, используемых командой Ьіпих сі опе, 
соответствует стандартному системному вызову 1ЖІХ Гогк? Созданию по¬ 
тока в ІЖІХ? 

19. Планировщик в системе Ьіпих вычисляет «добродетельность» процессов 
реального времени, добавляя к приоритету число 1000. Можно ли выбрать 
другую константу так, чтобы алгоритм продолжал выбирать те же процессы? 

20. При загрузке операционной системы 1ЖІХ (и большинства других опера¬ 
ционных систем) начальный загрузчик, хранящийся в 0-м секторе диска, 
загружает программу загрузки, которая, в свою очередь, загружает операци¬ 
онную систему. Зачем требуется этот лишний промежуточный этап? Ведь 
было бы проще, если начальный загрузчик, хранящийся в 0-м секторе дис¬ 
ка, загружал операционную систему напрямую. 

21. Предположим, что текстовый редактор состоит из 100 Кбайт программного 
кода, 30 Кбайт инициализированных данных и 50 Кбайт В55. Начальный 
размер стека составляет 10 Кбайт. Одновременно запускаются три копии 
этого редактора. Сколько потребуется физической памяти (а) если исполь¬ 
зуется общий текстовый сегмент и (б) если используется общий текстовый 
сегмент? 

22. В 4В5В каждая запись карты памяти содержит индекс для следующей за¬ 
писи в списке свободных страниц, используемый, когда текущее значение 
находится в списке свободных страниц. Размер поля 16 бит. Размер страниц 
1 Кбайт. Влияют ли эти размеры на общий объем памяти, поддерживаемый 
В5Б? Аргументируйте свой ответ. 

23. В В50 сегменты данных и стека подкачиваются постранично и выгружают¬ 
ся во временные копии, хранящиеся на специальном диске или дисковом 
разделе подкачки, но для подкачки текстового сегмента используется сам 
исполняемый файл. Почему? 
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24. Опишите способ использования системного вызова пиар и сигналов для со¬ 
здания механизма межпроцессного взаимодействия. 

25. Файл отображается на память с помощью системного вызова ттар следую¬ 
щим образом: 

ттар(65536, 32768. КЕДИ. ГІ_А65. 0) 

Размер страниц 8 Кбайт. Какой байт файла будет считан при обращении к 
адресу памяти 72 000? 

26. После выполнения системного вызова из предыдущей задачи процесс обра¬ 
щается к системному вызову 

типтар(65536, 8192) 

Будет ли он выполнен успешно? Если да, то какие байты файла останутся 
отображенными на память? 

27. Может ли страничное прерывание привести к завершению работы процес¬ 
са, вызывавшего это прерывание? Если да, приведите пример. Если нет, то 
почему нет? 

28. Возможно ли, чтобы при использовании «приятельской» системы управле¬ 
ния памятью два соседних свободных блока одинакового размера сосуще¬ 
ствовали и не были объединены в один блок? Если да, приведите пример, 
как это может произойти. Если нет, докажите, что это невозможно. 

29. В тексте утверждалось, что производительность страничной подкачки выше 
при выгрузке на отдельный раздел диска, а не в файл. Почему это так? 

30. Приведите два примера преимущества относительных путей перед абсолют¬ 
ными. 

31. Несколько процессов обращается к вызовам блокировки. Скажите, что про¬ 
изойдет при каждом обращении. Если процесс не может получить блоки¬ 
ровку, то он блокируется сам. 

а) процесс А хочет получить блокировку без монополизации байтов с 0 по 10; 

б) процесс В хочет получить блокировку с монополизацией байтов с 20 по 30; 
в ) процесс С хочет получить блокировку без монополизации байтов с 8 по 40; 

г) процесс А хочет получить блокировку без монополизации байтов с 25 по 35; 

д) процесс В хочет получить блокировку с монополизацией байта 8. 

32. Рассмотрим блокированный файл на рис. 10.16, в. Предположим, что про¬ 
цесс пытается получить блокировку байтов 10 и 11 и блокируется. Затем, 
прежде чем процесс С отпустит блокировку, еще один процесс пытается по¬ 
лучить блокировку байтов 10 и 11 и также блокируется. Какую проблему 
добавляет к семантике эта ситуация? Предложите и обоснуйте два решения. 

33. Предположим, что происходит обращение к системному вызову Ізеек с от¬ 
рицательным значением смещения в файле. Дайте два возможных варианта 
обработки данной ситуации. 

34. Какой доступ получают к файлу его владелец, группа владельца и все осталь¬ 
ные пользователи, если режим защиты файла равен 755 (восьмеричное)? 
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35. У некоторых накопителей на магнитной ленте есть нумерованные блоки и 
возможность перезаписывать определенные блоки, не затрагивая соседние 
с ним блоки. Может ли подобное устройство содержать монтированную 
файловую систему ІЛЧІХ? 

36. На рис. 10.14 после создания связи у Фреда и Лизы есть доступ к файлу х 
в своих каталогах. Является ли доступ к этому файлу абсолютно симмет¬ 
ричным, то есть обладают ли оба пользователя одинаковыми правами по от¬ 
ношению к этому файлу? 

37. Как было показано, абсолютные пути файлов отсчитываются от корневого 
каталога, а относительные — от рабочего каталога. Предложите эффектив¬ 
ный способ реализации обоих способов поиска файлов. 

38. Когда открывается файл /и$г/а5І/тогк/^, требуется несколько обращений к 
диску, чтобы прочитать і-узел и блоки каталога. Сосчитайте количество не¬ 
обходимых дисковых обращений при условии, что і-узел и корневой ката¬ 
лог постоянно находятся в памяти, а размер всех каталогов один блок. 

39. І-узел в системе ІЖІХ содержит 10 дисковых адресов для блоков данных, 
а также адреса однократного, двукратного и трехкратного косвенных блоков. 
Чему равен максимальный размер файла в операционной системе СГШХ, 
если каждый из косвенных блоков может содержать 256 дисковых адресов, 
а размер дискового блока равен 1 Кбайт? 

40. Когда при открытии файла с диска считывается і-узел, он помещается в таб¬ 
лицу і-узлов, хранящуюся в памяти. В этой таблице есть поля, отсутству¬ 
ющие на диске. Один из них — это счетчик, отслеживающий количество 
обращений к і-узлу. Зачем нужно это поле? 

41. Почему для управления буферным кзшем применяется алгоритм ЫШ, в то 
время как он редко используется для слежения за страницами в системе вир¬ 
туальной памяти? 

42. В операционной системе ІЖІХ есть системный вызов зупс, выгружающий 
модифицированные блоки буферного кэша на диск. При загрузке системы 
запускается программа ирсіаіе. Каждые 30 с она обращается к системному 
вызову зупс, после чего отправляется спать еще на 30 с. Зачем нужна такая 
программа? 

43. Когда операционная система перезагружается после сбоя, как правило, вы¬ 
полняется программа восстановления. Предположим, эта программа обна¬ 
руживает, что значение счетчика связей в і-узле равно 2, тогда как только 
одна каталоговая запись ссылается на данный і-узел. Может ли программа 
восстановления исправить такую ошибку, и если да, то как? 

44. Попытайтесь угадать, который системный вызов ІЖІХ выполняется быст¬ 
рее всего. 

45. Возможно ли удалить связь файла, для которого связь никогда не создава¬ 
лась? Что произойдет? 

46. Основываясь на информации, предоставленной в данной главе, определи¬ 
те, какой максимальный объем данных пользователя можно разместить на 
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дискете емкостью 1,44 Мбайт, если использовать файловую систему Ьіпих 
ехГ2? Предположим, что размер блоков диска равен 1 Кбайт. 

47. Учитывая все неприятности, которые могут причинить студенты, если они 
получат права доступа суперпользователя, можете ли вы сказать, зачем вооб¬ 
ще существует понятие суперпользователя? 

48. Профессор пользуется общими файлами вместе со своими студентами, поме¬ 
щая их в каталог, к которому предоставлен публичный доступ. Этот каталог 
расположен в системе ІЛЧІХ компьютера факультета кибернетики. Однажды 
профессор спохватывается, что разрешил доступ записи к одному из файлов 
для всех пользователей. Он изменяет разрешения доступа и убеждается, что 
файл соответствует оригиналу. На следующий день профессор обнаружи¬ 
вает, что файл был изменен. Как это могло произойти и как это можно было 
предотвратить? 

49. Напишите минимальную оболочку, способную выполнять простые команды. 
Она также должна быть способна запускать эти команды в фоновом режиме. 

50. С помощью ассемблера и системных вызовов ВІ05 напишите программу, 
загружающуюся с гибкого диска на компьютере с процессором РепНшті. Эта 
программа должна использовать вызовы ВІ05 для чтения ввода с клавиа¬ 
туры и вывода эха вводимых символов на экран, просто чтобы продемонст¬ 
рировать, что она работает. 

51. Напишите программу для неинтеллектуального терминала, позволяющую 
соединить две рабочие станции, управляемые операционными системами 
ЬПЧІХ или Ьіпих, через последовательные порты. Используйте системные 
вызовы стандарта Р05ІХ для настройки портов. 
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\Уіп(іо\У5 2000 — это современная операционная система, работающая на на¬ 
стольных персональных компьютерах старших моделей и серверах. Данная глава 
посвящается различным аспектам этой системы. Мы начнем ее изучение с истории, 
затем перейдем к архитектуре системы. После этого мы рассмотрим процессы, 
управление памятью, ввод-вывод, файловую систему и, наконец, систему безопас¬ 
ности. Мы не станем рассматривать сетевые аспекты, так как одна эта тема легко 
может растянуться на целую главу или даже целую книгу. 


История ѴѴіпсІоѵѵз 2000 

Операционные системы корпорации МісгозоД для настольных и переносных компь¬ 
ютеров можно разделить на три семейства: МЗ-БОЗ, Сопзшпег \Ѵіпсіо\ѵ5 (\Ѵіп- 
(іо\У5 95/98/Ме) и \Утс1о\ѵ5 ИТ. Ниже мы кратко опишем каждое из этих семейств. 

М8-РОЗ 

В 1981 году корпорация ІВМ, в то время крупнейшая и мощнейшая компьютер¬ 
ная компания мира, создала персональный компьютер ІВМ РС, основанный на 
процессоре Іпіеі 8088. Персональный компьютер был оснащен 16-разрядной од¬ 
нопользовательской операционной системой реального режима с командной стро¬ 
кой, названной МЗ-БОЗ 1.0. Эта операционная система поставлялась крохотной 
начинающей фирмой МісгозоД, большей частью известной в те годы как создатель 
интерпретатора В А5ІС для систем на базе процессоров Іпіеі 8080 и 2і1о§ 280. Опе¬ 
рационная система состояла из резидентной программы размером в 8 Кбайт, доволь¬ 
но близко копирующей СР/М, примитивную операционную систему для 8-раз- 
рядных процессоров Іпіеі 8080 и 2і1о§ 280. Два года спустя была выпущена более 
мощная операционная система М5-Б05 2.0, состоящая из 24 Кбайт резидентного 
кода. Она содержала программу обработки командной строки (оболочку) с боль¬ 
шим количеством функций, позаимствованных у операционной системы ИМХ. 

Когда фирма Іпіеі выпустила 286-й процессор, корпорация ІВМ создала на его 
основе новый компьютер, РС/АТ, выпущенный в 1986 году. Буквы АТ означали 



История ѴѴіпбоѵѵз 2000 


837 


Асіѵапсесі ТесЬпо1о§у (передовая технология), так как процессор Іпгеі 286 работал 
на впечатляющей тогда частоте в 8 МГц и мог адресоваться (правда, с большим 
трудом) к 16 Мбайт памяти. На практике у большинства систем было максимум 
1 Мбайт или 2 Мбайт, поскольку память в те времена стоила очень дорого. Персо¬ 
нальный компьютер ІВМ РС/АТ поставлялся вместе с операционной системой 
МЗ-ИОЗ 3.0 фирмы МісгозоЙ, занимавшей в памяти 36 Кбайт. С годами в опера¬ 
ционной системе М5-И05 появилось много новых функций, но она по-прежнему 
оставалась операционной системой, ориентированной на командную строку. 

ѴѴіпсіоѵѵз 95/98/Ме 

Вдохновленная пользовательским интерфейсом компьютера Арріе Ьіза, предше¬ 
ственника Арріе МасіпІозЬ, корпорация МісгозоД решила добавить к операционной 
системе М5-И05 графический интерфейс пользователя (оболочку), которую она 
назвала "ѴѴіпсІолѵз. Операционная система "\Утс1о\у5 1.0, выпущенная в 1985 году, 
была чем-то вроде суррогата. Версия \Ѵіп(іо\ѵ5 2.0, разработанная для РС/АТ и 
выпущенная в 1987 году, была не намного лучше. Наконец, операционная система 
\Уіпсіо\у5 3.0 для персонального компьютера с центральным процессором Іпіеі 386 
(выпущенная в 1990 году), и особенно последовавшие за ней версии 3.1 и 3.11 до¬ 
бились большого коммерческого успеха. Ни одна из этих ранних версий \УіпсІо\у5 
не являлась настоящей операционной системой, скорее графическим интерфейсом 
пользователя поверх М5-И05, которая продолжала управлять машиной и файло¬ 
вой системой. Все программы работали в одном и том же адресном пространстве, 
и ошибка в одной из них могла повесить всю систему. 

Выход в августе 1995 года \Ѵіп<іо\ѵз 95 до сих пор не привел к полному вы¬ 
теснению системы МЗ-ИОЗ, хотя почти все функции МЗ-ИОЗ были перенесены 
в \Ѵіп(іо\ѵ5. Как \Ѵіп(іо\ѵ5 95, так и новая версия М5-И05 7.0 содержали большин¬ 
ство особенностей монолитной операционной системы, включая виртуальную па¬ 
мять и управление процессами. Однако операционная система \Ут<іо\у5 95 не была 
полностью 32-разрядной программой. Она содержала большие куски 16-раз- 
рядного ассемблерного кода (а также немного 32-разрядного) и продолжала ис¬ 
пользовать файловую систему М5-И05, практически со всеми ее ограничениями. 
Единственное значительное изменение файловой системы заключалось в добав¬ 
лении длинных имен файлов к именам из 8 + 3 символа, разрешенным в М5-И05. 

Даже в выпуске "\Утс1о\у8 98 в июне 1988 года М5-И05 все еще присутствова¬ 
ла (теперь она называлась версией 7.1) и состояла из 16-разрядного кода. Хотя те¬ 
перь еще больше функций было переведено из МЗ-ИОЗ-части системы в часть 
\Утс 1 о\у 5 , а поддержка больших дисковых разделов стала стандартом, по своему 
строению операционная система \УіпсІо\ѵ5 98 не сильно отличалась от \Уіпсіо\уз 95. 
Основное отличие заключалось в интерфейсе пользователя, в большей степени 
интегрировавшем в себе Интернет и рабочий стол пользователя. Именно эта ин¬ 
теграция и привлекла внимание Министерства юстиции США, которое затем вы¬ 
двинула против корпорации МісгозоД иск, обвиняя корпорацию МісгозоЙ в нару¬ 
шении закона о монополиях. Корпорация МісгозоЙ яростно отрицала свою вину. 
В апреле 2000 года Федеральный суд США согласился с правительством. 
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Кроме того, что в ядре операционной системы \Ѵігкіо\У5 98 содержался боль¬ 
шой кусок 16-разрядного ассемблерного кода, у этой системы были еще две серь¬ 
езные проблемы. Во-первых, хотя эта система была многозадачной, само ядро не 
было реентерабельным. Если процесс был занят управлением какой-либо струк¬ 
турой данных в ядре, а затем его квант времени заканчивался и начинал работу 
другой процесс, новый процесс мог получить структуру данных в противоречивом 
состоянии. Чтобы предотвратить возникновение подобной проблемы, большинство 
процессов, зайдя в ядро, первым делом получали гигантский мьютекс, покрываю¬ 
щий всю систему, прежде чем приступить к каким-либо действиям. Хотя такой 
подход и устранял потенциальную угрозу противоречивости структур данных, он 
также уничтожал большую часть преимуществ многозадачности, так как процессам, 
чтобы войти в ядро, часто приходилось ждать, пока другой процесс ядро покинет. 

Во-вторых, у каждого процесса было 4-гигабайтное адресное пространство, 
в котором первые 2 Гбайт полностью принадлежали процессу. Однако следующий 
1 Гбайт совместно использовался (с возможностью записи) всеми процессами си¬ 
стемы. Нижний 1 Мбайт также совместно использовался всеми процессами, что¬ 
бы все они могли получать доступ к векторам прерывания М5-005. Эта возмож¬ 
ность вовсю использовалась большинством приложений \Ѵіпс1о\ѵ5 98. В результате 
ошибка в одной программе могла повредить ключевые структуры данных, исполь¬ 
зуемые посторонними процессами, вследствие чего все эти процессы рушились. 
Что еще хуже, последний 1 Гбайт совместно использовался (с возможностью за¬ 
писи) процессами и ядром и содержал некоторые критические структуры данных. 
Любая программа, записав поверх этих структур какой-либо мусор (преднамерен¬ 
но или нет), могла вывести из строя всю систему. Очевидное решение, заключаю¬ 
щееся в том, чтобы не помещать структуры данных ядра в пространство пользова¬ 
теля, было неприменимо, так как старые программы, написанные для МЗ-ЭОЗ, не 
смогли бы тогда работать в \Ѵіпс1о\ѵ5 98. 

В 2000 году корпорация МісгозоЙ выпустила слегка измененную версию си¬ 
стемы \УіпсІо\У5 98, названную "ѴѴіпсіолѵя Ме (\Ѵіпс1о\ѵ5 МіПеппіит Есііііоп — \Уіп- 
с1о\У5, выпуск тысячелетия). Хотя в данной версии были исправлены некоторые 
ошибки, а также добавлены новые функции, под внешней оболочкой скрывалась 
все та же \Ѵіпс1о\ѵ5 98. Новые функции включали в себя улучшенные возможнос¬ 
ти организации и совместного использования изображений, музыки и фильмов, 
серьезнее поддерживали работу с сетью на дому и многопользовательские игры, 
а также содержали больше функций, относящихся к Интернету, таких как под¬ 
держка мгновенных сообщений и широкополосных соединений (кабельных мо¬ 
демов и АОЗЬ). Одна интересная новая функция состояла в возможности вос¬ 
становить прежние настройки компьютера после неверной установки каких-либо 
параметров. Если пользователь перенастраивал систему (например, изменял раз¬ 
решение экрана с 640 х 480 на 1024 х768), и после этого система переставала 
работать, теперь он мог вернуться к последней работающей конфигурации. 


ѴѴіпсІоѵѵз ІМТ 

К концу 80-х корпорация МісгозоЙ осознала, что построение современной 32-раз- 
рядной операционной системы поверх 16-разрядной системы М8-В05 представля- 
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ет собой не лучшее решение. Компания МісгозоЙ: наняла Дэвида Катлера, одного 
из ключевых разработчиков операционной системы ѴМ5, созданной корпораци¬ 
ей ОЕС, и поручила ему возглавить работу над совершенно новой 32-разрядной 
операционной системой, совместимой с ѴѴіпсІоѵѵз. Эта новая система, названная 
позднее ѴѴіпсІоѵѵз ЫТ (буквы ЫТ означали Ыеѵѵ ТесЬпо1о§у — новая технология), 
предназначалась для деловых приложений, решающих критически важные, от¬ 
ветственные задачи, а также для домашнего использования. В это время мэйн¬ 
фреймы все еще правили деловым миром, поэтому предположение, что компании 
будут использовать персональные компьютеры для чего-либо важного, тогда вы¬ 
глядело довольно утопично. Тем не менее, как показала история, это был правиль¬ 
ный выбор. Такие свойства, как безопасность и высокая надежность, отсутство¬ 
вавшие в версиях ѴѴіпсІоѵѵз, основанных на М5-005, были поставлены в данном 
проекте во главу угла. Опыт работы с ѴМ5, полученный Катлером, отчетливо про¬ 
являлся при создании системы, и в строении ИТ и ѴМ5 есть нечто большее, чем 
просто поверхностное сходство. 

Проект оказался успешным, и в 1993 году была выпущена первая версия, 
названная ѴѴіпсІоѵѵз ИТ 3.1. Начальный номер версии был выбран так, чтобы он 
соответствовал номеру версии популярной тогда 16-разрядной ѴѴіпсІоѵѵз 3.1. 
Корпорация МісгозоД ожидала, что операционная система ЫТ быстро вытес¬ 
нит ѴѴіпсІоѵѵз 3.1, так как по формальным показателям ИТ значительно превос¬ 
ходила ее. 

К большому удивлению разработчиков, почти все пользователи предпочли 
остаться на уже знакомой им старой 16-разрядной версии, а не переходить на не¬ 
известную 32-разрядную систему, какой бы хорошей она ни была. Для операци¬ 
онной системы ЫТ требовалось значительно больше памяти, чем для ѴѴіпсІоѵѵз 3.1, 
к тому же для новой системы не было 32-разрядных программ, поэтому зачем нуж¬ 
ны были пользователям все эти хлопоты? Поскольку операционная система ИТ 3.1 
потерпела неудачу на рынке, корпорация МісгозоД решила выпустить 32-раз¬ 
рядную версию ѴѴіпсІоѵѵз 3.1, а именно ѴѴіпсІоѵѵз 95. Пользователи продолжали 
упорствовать, не желая переходить на ЫТ, и корпорация МісгозоД выпустила 
ѴѴіпсІоѵѵз 98 и, наконец, ѴѴіпсІоѵѵз Ме. О каждой из которых заявлялось, что это 
самый последний выпуск операционной системы, основанной на МЗ-ООЗ. 

Несмотря на тот факт, что почти все покупатели и большинство корпораций 
проигнорировало операционную систему 1ЧТ 3.1 для настольных систем, эта 
операционная система стала пользоваться некоторым спросом на рынке серверов. 
В 1994 и 1995 годах было выпущено несколько новых 3.x версий с небольшими 
изменениями. Эти версии начали также медленно приобретать сторонников среди 
пользователей настольных машин. 

Первое значительное усовершенствование системы ЫТ появилось в 1996 году 
в виде версии ЫТ 4.0. Эта система обладала мощностью, безопасностью и надеж¬ 
ностью современной операционной системы, но она также использовала тот же 
самый пользовательский интерфейс, что и очень популярная тогда ѴѴіпсІоѵѵз 95. 
Эта совместимость облегчала пользователям переход с ѴѴіпсІоѵѵз 95 на ИТ, и мно¬ 
гие пользователи так и поступили. Некоторые отличия между ѴѴіпсІоѵѵз 95/98 
и ѴѴіпсІоѵѵз ИТ приведены в табл. 11.1. 
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Таблица 11.1. Некоторые отличия между ѴѴІпсіоѵѵз 95/98 и ѴѴІпсіоѵѵз N1 

Аспект 

ѴѴІпсіоѵѵз 95/98 

ѴѴІпсіоѵѵз ЫТ 

Полностью 32-разрядная система? 

Нет 

Да 

Безопасность? 

Нет 

Да 

Защищенное отображение файлов? 

Нет 

Да 

Приватное адресное пространство для каждой 
программы М5-Р05? 

Нет 

Да 

ІІпісосІе? 

Нет 

Да 

Процессор 

Іпіеі 80x86 

80x86, АІрІта, МІР5, ... 

Многопроцессорная поддержка? 

Нет 

Да 

Реентерабельность кода операционной системы? 

Нет 

Да 

РІид апсі ріау? 

Да 

Нет 

Управление питанием? 

Да 

Нет 

Файловая система РАТ-32? 

Да 

По желанию 

Файловая система ИТРЗ? 

Нет 

Да 

ѴѴіп32 АРІ? 

Да 

Да 

Поддержка всех старых программ М5-Р05? 

Да 

Нет 

Критические данные ОС, доступные 
пользователю для записи? 

Да 

Нет 


С самого начала операционная система ЫТ разрабатывалась в расчете на пере¬ 
носимость системы на другие платформы, поэтому она была практически полнос¬ 
тью написана на С с очень небольшими включениями на ассемблере для низко¬ 
уровневых функций, таких как обработка прерываний. Первый выпуск состоял из 
3,1 млн строк на С для операционной системы, библиотек и подсистем окружения 
(они будут обсуждаться ниже). Когда вышла ЫТ 4.0, программная основа выросла 
до 16 млн строк кода, все так же большей частью на языке С, хотя для написания 
пользовательского интерфейса было использовано некоторое количество С++. 
К этому времени система обладала высокой переносимостью, различные ее версии 
работали на компьютерах с процессорами Репііит, АІрЬа, МІР5 и Ро\ѵег РС, а так¬ 
же некоторых других. С тех пор некоторые из этих версий перестали поддержи¬ 
ваться. История развития ]\ІТ приведена в [367]. В этой книге также много расска¬ 
зывается о ключевых участниках этой истории. 


ѴѴІпсіоѵѵз 2000 

Следом за 1ЧТ 4.0 предполагалось выпустить версию ЫТ 5.0. Однако в 1999 году 
корпорация Місгозой изменила ее название на АѴіпсіоѵуз 2000, в основном из-за 
попыток найти нейтральное имя, выглядящее логическим продолжением как для 
пользователей \Ѵіпс1о\У5 98, так и для пользователей ИТ. Таким образом, корпора¬ 
ция МісгозоФ рассчитывала иметь единую операционную систему, построенную 
на основе надежной 32-разрядной технологии, но использующую популярный 
интерфейс пользователя системы \Ѵіпс1о\У5 98. 

Поскольку в действительности операционная система АѴіпскпуз 2000 пред¬ 
ставляет собой ЫТ 5.0, она унаследовала множество свойств системы ЫТ 4.0. Она 
является полностью 32-разрядной (планируется переход на 64-разрядную) мно- 
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гозадачной системой с индивидуально защищенными процессами. У каждого про¬ 
цесса есть собственное 32-разрядное (будет 64-разрядное) виртуальное адресное 
пространство. Операционная система работает в режиме ядра, тогда как процессы 
пользователя работают в пользовательском режиме, что обеспечивает полноцен¬ 
ную защиту (в отличие от \Ѵіпс1о\Ѵ5 98). У процессов может быть один или не¬ 
сколько потоков, видимых для операционной системы и управляемых ею. Она 
удовлетворяет требованиям безопасности уровня С2 Министерства обороны США 
для всех файлов, каталогов и процессов, а также других объектов, которые могут 
использоваться совместно (по крайней мере, если гибкий диск вынут, а сеть от¬ 
ключена). Наконец, она обладает полной поддержкой симметричных многопро¬ 
цессорных систем с числом процессоров от 2 до 32. 

Тот факт, что \Ѵіпс1о\ѵ5 2000 в действительности представляет собой ЫТ 5.0, 
проявляется во многом. Например, системный каталог называется \тппС, а дво¬ 
ичный файл операционной системы (в каталоге \тппі\5у5іет32) называется 
піовкті.ехе. Если щелкнуть на этом файле правой кнопкой мыши и посмотреть его 
свойства, мы увидим, что номер его версии представляет собой 5.ххх.ууу.222 , где 5 
означает ЕГГ 5, ххх — номер выпуска, ууу — номер сборки (компиляции), а ггг — 
дополнительный номер версии. Кроме того, многие файлы в каталоге \тппі и его 
подкаталогах содержат буквы пі в своих именах, как, например, виртуальный эму¬ 
лятор М5-Э05 пСѵсІт. 

Операционная система \Ѵіпс1о\Ѵ5 2000 — это не просто улучшенная версия ИТ 4.0 
с интерфейсом \Ѵіпс1о\Ѵ5 98. Начнем с того, что она содержит множество других 
функций, которые ранее были только в \Ѵіпс1о\У5 98. К ним относится полная под¬ 
держка устройств р1и§-апс!-р1ау, шины НЗВ, стандарта ІЕЕЕ 1394 (Ріге\Ѵіге), ІгЭА 
(Іпігагесі Эаіа Аззосіаііоп — стандарт на инфракрасную передачу данных и вывод 
на печать, разработанный ассоциацией ІгОА), а также, среди прочего, управление 
питанием. Кроме того, были добавлены несколько новых функций, не присутство¬ 
вавших ранее в других операционных системах корпорации МісгозоЛ, включая 
каталоговую службу Асііѵе Оігесіогу, систему безопасности КегЬегоз, поддержку 
смарт-карт, инструменты мониторинга системы, лучшую интеграцию лэптопов и 
настольных компьютеров, инфраструктуру системного администрирования и рабо¬ 
чие объекты. Другая новая особенность файловой системы ЩТ5 состоит в разно¬ 
видности связи с копированием при записи, при использовании которой два пользо¬ 
вателя могут совместно использовать один связанный файл. Как только один из 
пользователей начинает запись в этот файл, автоматически создается копия файла. 

Еще одно значительное усовершенствование заключается в интернационали¬ 
зации. Операционная система ЕГГ 4.0 поставлялась в виде отдельных версий для 
различных языков, так как текстовые строки были внедрены в программный код. 
При установке английского программного пакета на голландский компьютер часто 
части операционной системы переставали использовать голландский язык и пере¬ 
ходили на английский, поскольку определенные файлы, содержащие программные 
и текстовые строки, были перезаписаны. Эта проблема 1 была устранена. Опера- 


1 В действительности проблема несколько серьезнее. В конце концов, иностранный язык можно и вы¬ 
учить. Дело в том, что в операционных системах \Уіп<1оѵѵ5 (как 98, так и ОТ) многие пакеты постав¬ 
ляются вместе с библиотеками, на тот случай, если они не установлены в системе. Большинство 
же библиотек хранится в одном общем каталоге. Иногда неверно написанная программа установки 
пакета заменяет какой-либо ОІЩ-файл более старой версией, после чего перестают работать другие 
пакеты. — Примеч. перев. 
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ционная система \Ѵіпс1о\Ѵ5 2000 состоит из единого двоичного кода, работающего 
во всех странах мира. Для каждой установки системы и даже для каждого пользова¬ 
теля можно выбрать язык, который будет использоваться во время работы системы. 
Это возможно потому, что все пункты меню, строки диалоговых окон, сообщения 
об ошибках и другие текстовые строки были удалены из операционной системы 
и помещены в специальные каталоги, по одному для каждого языка. Как и преды¬ 
дущие версии операционной системы ЭТ, \Ѵіпбо\Ѵ5 2000 использует кодировку 
Ііпісосіе для поддержки языков, не использующих латинский алфавит, например 
русского, греческого, иврита и японского. 

Единственная вещь, которой нет в \Ѵіпбо\ѵ5 2000 — это МЗ-ЭОЗ. Ее просто нет 
здесь ни в каком виде (как не было в КТ). Есть интерфейс командной строки, но 
это новая 32-разрядная программа, включающая функциональность старой систе¬ 
мы МЗ-ЭОЗ, а также некоторые новые функции 1 . 

Несмотря на многочисленные свойства, способствующие переносимости сис¬ 
темы с точки зрения программ, аппаратуры, языков и т. д„ в одном отношении опе¬ 
рационная система Шіпсіоѵѵз 2000 обладает меньшей переносимостью, чем ИТ 4.0. 
Она работает только на двух платформах — Репііит и Іпіеі ІА-64 2 . Изначально 
операционная система ИТ поддерживала дополнительные платформы, включая 
РоѵѵегРС, МІРЗ и АІрЬа, но с годами корпорация МісгозоЙ перестала поддержи¬ 
вать эти процессоры один за другим по коммерческим соображениям. 

Как и предыдущие версии ИТ, в настоящее время \Ѵіпс1о\Ѵ5 2000 поставляется в 
виде нескольких уровней продукта: Ргоіеззіопаі, Зегѵег, Абѵапсесі зегѵег и ИаГасеШег 
Зегѵег. Однако различия между этими версиями незначительны, и во всех версиях 
используется один и тот же исполняемый двоичный код. При установке системы 
тип продукта записывается во внутренней базе данных (системном реестре). Во 
время загрузки операционная система проверяет содержимое реестра, определяя 
версию программного продукта. Различия между ними показаны в табл. 11.2. 


Таблица 11.2. Различные версии ѴѴіпсІоѵѵз 2000 


Версия 

Максимальный 
размер ОЗУ, Гбайт 

СРІІ 

Максимальное 
число клиентов 

Размер 

кластера 

Оптимизация 

Ргоіеззіопаі 

4 

2 

10 

0 

Время отклика 

Зегѵег 

4 

4 

Не ограничено 

0 

Пропускная 

способность 

Асіѵапсесі зегѵег 

8 

8 

Не ограничено 

2 

Пропускная 

способность 

Оаіасепіег зегѵег 

64 

32 

Не ограничено 

4 

Пропускная 

способность 


Как видно из таблицы, различия включают максимальный размер поддержи¬ 
ваемой оперативной памяти, максимальное количество центральных процессоров 
(для многопроцессорной конфигурации) и максимальное число клиентов, кото- 

1 16-разрядного кода в ІЧТ действительно нет, но это не мешает запускать в ЫТ и в \Ѵіпс1о\ѵ5 2000 боль¬ 
шинство старых 16-разрядных программ, написанных для МЗ-ИОЗ и \ѴіпсІо\ѵ5 3.1. Для этого в сис¬ 
теме содержится специальная система эмуляции 16-разрядной машины. — Примеч. перев. 

2 Пока что существует лишь в виде эмулятора. — Примеч. перев. 







История ѴѴІпсіоѵѵз 2000 


843 


рые могут быть обслужены данной системой в качестве сервера. Размер класте¬ 
ра означает способность операционной системы Шіпбо\ѵ5 2000 представить для 
окружающего мира две или четыре отдельные машины в виде одного сервера, 
что часто бывает полезно, например, для \ѵеЬ-серверов. Наконец, на \Ѵіпс1о\ѵз 2000 
Ргоіеззіопаі по-другому настраиваются параметры по умолчанию. В этой системе 
интерактивным процессам предоставляется преимущество перед пакетными за¬ 
даниями, хотя это можно изменить, если необходимо. Последнее отличие за¬ 
ключается в том, что на серверах, в отличие от \Ѵіпбо\ѵз 2000 Ргоіеззіопаі, предо¬ 
ставляется дополнительное программное обеспечение, а с системой \Ѵіпбо\ѵз 2000 
Оаіасепіег зегѵег поставляются дополнительные средства управления большими 
заданиями. 

Причина существования нескольких версий является исключительно коммер¬ 
ческой: это позволяет корпорации Місгозоіі получать с крупных компаний боль¬ 
ше денег, чем с индивидуальных клиентов, за практически один и тот же программ¬ 
ный продукт. Идея эта не нова и корпорация Місгозоіі не уникальна в применении 
такой рыночной тактики. Уже много лет авиалинии берут с деловых пассажиров 
за полет тем же рейсом значительно большую сумму. Причем не только за бизнес- 
класс, но также и за возможность покупки билета за день до полета вместо тради¬ 
ционного заказа за месяц. 

Формально различием в версиях управляют в нескольких местах программы 
всего две переменные, считываемые из реестра: Рго&исіТуре и РгосІисіЗиііе. В зави¬ 
симости от их значений выполняется слегка отличный код. Изменение значений 
этих переменных рассматривается как нарушение лицензии. Кроме того, система 
перехватывает любые попытки изменить их и регистрирует эти попытки нестира¬ 
емым способом, так что впоследствии можно доказать факт нарушения лицензии. 

Кроме основной операционной системы, корпорация Місгозоіі также разра¬ 
ботала несколько инструментальных программ для продвинутых пользователей. 
К этим программам относятся Зиррогі Тооіз, ЗоіІ\ѵаге Оеѵеіоршепі Кіі, Огіѵег 
Оеѵеіоршепі Кіі и Кезоигсе Кіі. Это большие наборы утилит для отладки и монито¬ 
ринга системы. Инструментарий поддержки распространяется на компакт-диске 
\Ѵітіс1о\ѵ5 2000 в каталоге \зиррогі\ІооІ5. Файлы не устанавливаются стандартной 
процедурой, но их можно установить специальной программой зеіир.ехе, располо¬ 
женной в этом же каталоге. ЗИК и ИИК разработчики могут получить в Интер¬ 
нете по адресу тзсіп.тісгозо/і.сот. Кезоигсе Кіі представляет собой розничный 
продукт корпорации Місгозоіі. Кроме того, существует множество утилит для 
слежения за внутренней работой Шіпс1о\Ѵ5 2000, разработанных другими компани¬ 
ями. Например, прекрасный набор инструментов можно бесплатно скачать с \ѵеЬ- 
сайта ѵѵѵѵѵѵ.зузіпіегпаіз.сот. Некоторые из этих программ даже предоставляют боль¬ 
ше информации, чем соответствующие инструменты корпорации Місгозоіі. 

\Ѵіпс1о\ѵ5 2000 представляет собой чрезвычайно сложную систему, на сегод¬ 
няшний день состоящую более чем из 29 млн строк на С. Если распечатать это по 
50 строк на странице и сброшюровать по 1000 страниц в книге, то полный код зай¬ 
мет 580 томов. Для такого опуса потребуется 23 погонных метра полочного про¬ 
странства (для версии в мягкой обложке). Если же эти книжные полки располо¬ 
жить в виде книжных шкафов, шириной в 1 м и в 6 полок высотой, то понадобится 
4 таких шкафа, чтобы вместить распечатанный исходный текст системы. 
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Шутки ради в табл. 11.3 приведены данные об объеме исходного текста различ¬ 
ных операционных систем. (В первой строке каждой ячейки таблицы содержится 
версия системы, вторая строка представляет собой количество строк исходного 
текста, где К = 1000, а М = 1 000 000.) Однако следует очень осторожно сравни¬ 
вать различные операционные системы в этой таблице, так как то, что составляет 
операционную систему, отличается от системы к системе. Например, вся оконная 
система и графический интерфейс пользователя являются частью ядра в \Ѵіпс1о\ѵ5, 
но не входят в ядро ни в одной из версий системы ІЖІХ. В них это просто пользо¬ 
вательский процесс. С учетом X \Ѵіпс1о\У5 ко всем версиям ІШІХ добавится 1,5 млн 
строк кода, а ведь при этом даже не учитывается исходный текст графического 
интерфейса пользователя (Моііі, СРЮМЕ и т. д.), который также не является ча¬ 
стью операционной системы ІЖІХ. Кроме того, некоторые системы содержат код 
для различных архитектур (например, пять для 4.4В5О и девять для Ілпих), при 
этом каждая архитектура добавляет от 10 000 до 50 000 строк кода. Причина, по 
которой операционная система Ргее В50 1.0 состоит всего лишь из 235 000 строк 
кода, тогда как 4В50 Іліе, от которой она произошла, состояла из 743 000 строк, 
заключается в том, что из Ргее В50 была выброшена поддержка всех устаревших 
архитектур (например, ѴАХ). 


Таблица 11.3. Сравнение размеров некоторых операционных систем 


Год АТ&Т 


В8Р 


МІЖХ 


Упих 


Зоіагіз 


ѴѴіп N1 


1976 Ѵ6 9К 

1979 Ѵ7 21К 

1980 

1982 Зуз III 58 К 
1984 

1986 

1987 ЗѴР3 92К 
1989 ЗѴР4 280К 


4.1 38 К 

4.2 98 К 

4.3 179 К 


1.0 13К 


1991 


0.01 10 К 



1993 

Ргее 1.0 235 К 


5.3 850 К 

3.1 6М 

1994 

4.4 І_і1е 743 К 

1.0 165 К 


3.5 ЮМ 

1996 


2.0 470 К 


4.0 16 М 

1997 

2.0 62 К 


5.6 1,4 М 


1999 


2.2 1 М 



2000 

Ргее 4.0 1,4 М 


5.8 2,0 М 

2000 29 М 


В различных системах также очень сильно разнится количество файловых си¬ 
стем, драйверов устройств и поставляемых библиотек. К тому же система \Ѵт<іо\У5 
содержит большое количество тестового кода, которого не содержит ІЖІХ, неко¬ 
торые утилиты и поддержку большого числа других языков, помимо английского. 
Наконец, эти измерения производились различными людьми, что тоже повлияло 
на разницу в учете (например, следует ли учитывать сборочные файлы проектов, 
заголовочные файлы и документацию?). Таким образом, это больше напоминает 
сравнение яблок не с апельсинами, а с телефонными аппаратами. Однако все учет- 
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ные данные внутри одного семейства операционных систем поступали из одного 
источника, поэтому сравнение внутри одного семейства имеет некоторый смысл. 

Несмотря на все вышесказанное, два вывода очевидны: 

1. Распухание операционных систем, похоже, так же неотвратимо, как смерть 
и налоги. 

2. Система \УтсІо\Ѵ5 значительно превосходит ІЖІХ в размерах. 

Что считать лучшим — большие или компактные системы, — до сих пор остается 
предметом жарких споров. Аргумент в пользу компактных систем заключается в 
том, что концепция небольших размеров и принцип «ничего лишнего» приводит к 
созданию управляемых, надежных систем, понятных для пользователя. В пользу 
больших систем приводится обычно тот аргумент, что пользователю, мол, требу¬ 
ется много различных функций. В любом случае должно быть ясно, что студенты, 
планирующие написать с нуля полноценную, современную операционную систе¬ 
му, берут на себя совершенно непосильную задачу. 

Хотя \Ѵіпбо\Ѵ5 2000 уже сейчас является чемпионом мира в тяжелом весе, если 
считать чистую массу, эта операционная система все продолжает расти, ошибки 
устраняются, а новые функции добавляются. Довольно интересен способ, которым 
корпорация МісгозоД управляет разработкой операционной системы. Сотни про¬ 
граммистов целый день работают над различными аспектами \Ѵіпс1о\ѵх 2000. Когда 
кусок программы закончен, программист посылает его по сети команде сборщиков. 
Каждый день в 18:00 дверь закрывается и система собирается заново (то есть пере¬ 
компилируется и компонуется). Каждая собранная таким образом версия системы 
получает порядковый номер, который можно увидеть в параметрах файла пШктіехе 
(первый опубликованный выпуск системы \Ѵіпбоѵѵ5 2000 имел номер 2195). 

Затем новая операционная система, опять же по сети, распространяется на ты¬ 
сячи машин кампуса корпорации МісгозоД в Редмонде, штат Вашингтон, где ее 
всю ночь подвергают интенсивному тестированию. Ранним утром следующего дня 
результаты тестирования рассылаются соответствующим группам, чтобы они мог¬ 
ли видеть, как работают их новые программы. Затем каждая группа программистов 
решает, над какой программой они будут работать в этот день. Затем снова насту¬ 
пает 18:00, и весь цикл повторяется. 


Программирование в ѴѴіпсІоѵѵз 2000 

Теперь настала пора начать изучение технических аспектов операционной систе¬ 
мы \Ѵтбо\ѵ5 2000. Однако, прежде чем приступить к рассмотрению деталей внут¬ 
ренней структуры системы, обсудим программный интерфейс и реестр, небольшую 
базу данных, хранящуюся в памяти системы. 

Программный интерфейс ѴѴіп32 АРІ 

Как и в других операционных системах, в \Ѵіпбо\ѵз 2000 есть свой набор системных 
вызовов, которые она может выполнять. Однако корпорация МісгозоЛ никогда не 
публиковала список системных вызовов \Ѵіпс1о\ѵх, кроме того, она постоянно меня- 
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ет их от одного выпуска к другому. Вместо этого корпорация Місгозоіі определи¬ 
ла набор функциональных вызовов, называемый \Ѵт32 АРІ (\Ѵт32 Арріісаііоп 
Рго§гаттіп§ Іпіегіасе — интерфейс прикладного программирования). Эти вызо¬ 
вы опубликованы и полностью документированы. Они представляют собой биб¬ 
лиотечные процедуры, которые либо обращаются к системным вызовам, чтобы 
выполнить требуемую работу, либо, в некоторых случаях, выполняют работу пря¬ 
мо в пространстве пользователя. Существующие вызовы ^іп32 АРІ не изменяют¬ 
ся с новыми выпусками системы \Ѵіп<іо\ѵ8, хотя часто добавляются новые вызовы 
\Ѵіп32 АРІ. 

Двоичные программы для процессоров Іпіеі х86, строго придерживающиеся 
интерфейса \Ѵіп32 АРІ, будут без каких-либо изменений работать на всех верси¬ 
ях \Ѵіпс1о\ѵ8, начиная с \Ѵіпйо\ѵ8 95. Как показано на рис. 11.1, для операционной 
системы \Ѵіпс1о\ѵ8 3.1 требуется дополнительная библиотека, преобразующая под¬ 
множество 32-разрядных вызовов \Ѵіп32 АРІ в 16-разрядные системные вызовы, 
но для остальных систем никакой адаптации не требуется. Следует отметить, что 
в операционной системе \Ѵіп<іо\ѵ8 2000 к интерфейсу \Ѵіп32 АРІ добавлено зна¬ 
чительное количество новых функций, поэтому в ней есть дополнительные вызо¬ 
вы АРІ, не включенные в старые версии \Ѵіп32, которые не будут работать на ста¬ 
рых версиях \Ѵіп<іо\ѵз. 



Рис. 11.1. Интерфейс ѴѴіп32 АРІ позволяет программам работать 
почти на всех версиях ѴѴІпсІоѵѵз 


Философия \Ѵіп32 АРІ полностью отлична от философии ІЖІХ. В операцион¬ 
ной системе ІЖІХ все системные вызовы опубликованы и формируют минималь¬ 
ный интерфейс: удаление даже одного из них приведет к снижению функциональ¬ 
ности операционной системы. Философия \Ѵіп32 заключается в предоставлении 
всеобъемлющего интерфейса, часто с возможностью выполнить одно и то же тре¬ 
мя или четырьмя способами, включающего множество функций (например, про¬ 
цедур). Эти функции, очевидно, не должны быть (и не являются) системными 
вызовами, как, например, вызов АРІ для копирования целого файла. 

Многие вызовы \Ѵш32 АРІ создают объекты ядра того или иного типа, напри¬ 
мер файлы, процессы, потоки, каналы и т. д. Каждый вызов, создающий объект, 
возвращает вызывающему процессу результат, называемый дескриптором. Этот 
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манипулятор может использоваться впоследствии для выполнения операций с объек¬ 
том. Дескриптор специфичен для процесса, создавшего этот объект. Он не может 
быть просто передан другому процессу и использован там (так же как дескрип¬ 
торы файлов в системе ІЖІХ не могут передаваться другим процессам). Однако 
при определенных обстоятельствах дескриптор может быть дублирован и передан 
другому процессу защищенным способом, что предоставляет второму процессу 
контролируемый доступ к объекту, принадлежащему первому процессу. С каждым 
объектом ассоциирован дескриптор безопасности, подробно описывающий, кто 
и какие действия может, а какие не может выполнять с данным объектом. 

Не все создаваемые системой структуры данных являются объектами, а также 
не все объекты являются объектами ядра. Только настоящие объекты ядра долж¬ 
ны иметь имена, защиту и могут совместно использоваться каким-либо образом. 
У каждого объекта ядра есть определенный системой тип, четко определенный 
набор операций, которые могут быть выполнены с объектом, и определенное мес¬ 
то хранения в ядре. Хотя пользователи могут выполнять операции с объектом (при 
помощи вызовов \Ут32 АРІ), но они не могут напрямую обращаться к объекту. 

Сама операционная система может также создавать и использовать объекты, 
чем она активно занимается. Большинство этих объектов создаются, чтобы по¬ 
зволить одному компоненту системы некоторое время хранить определенную ин¬ 
формацию или чтобы передать некоторую структуру данных другому компоненту 
системы. Например, при загрузке драйвера создается объект, в котором хранятся 
его свойства и указатели на содержащиеся в нем функции. Затем операционная 
система обращается к драйверу, используя этот объект. 

Иногда говорят, что система \Уіп<іо\Ѵ5 2000 является объектно-ориентирован¬ 
ной, так как единственный способ управления объектом заключается в вызове опе¬ 
раций, связанных с дескриптором объекта, путем обращения к вызовам \Уіп.32 АРІ. 
С другой стороны, в этой схеме отсутствуют основные свойства объектно-ориен¬ 
тированной системы, такие как наследование и полиморфизм. 

Вызовы \Уіп32 АРІ покрывают все мыслимые области, с которыми может ра¬ 
ботать операционная система, и довольно много областей, с которыми операцион¬ 
ная система, по идее, работать не должна. Естественно, этот интерфейс содержит 
вызовы для создания процессов и потоков и для управления ими. Также существу¬ 
ет множество вызовов, относящихся к межпроцессному (в действительности меж¬ 
поточному) взаимодействию. Это такие вызовы, как создание, уничтожение и ис¬ 
пользование мьютексов, семафоров, событий и других объектов ІРС (ІпІегРгосезз 
Сошшипісаііоп — межпроцессное взаимодействие). 

Хотя большая часть системы управления памятью невидима для программис¬ 
тов (по сути, она представляет собой просто страничную подкачку по требованию), 
одна важная функция видима, а именно способность процесса отображать файл 
на свою виртуальную память. Это предоставляет процессу возможность читать 
и писать части файла, как если бы они представляли собой просто слова в памяти. 

Важной частью многих программ является файловый ввод-вывод. С точки 
зрения \Ѵіп32, файл представляет собой просто линейную последовательность 
байтов. Интерфейс Шіп32 предоставляет более 60 вызовов для создания и унич¬ 
тожения файлов и каталогов, открытия и закрытия файлов, их чтения и записи, 
чтения и изменения атрибутов файлов и многого другого. 
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Другой областью, в которой интерфейс \Ѵіп32 предоставляет вызовы, являет¬ 
ся безопасность. У каждого процесса есть идентификатор, сообщающий о про¬ 
цессе, кто он есть. А у каждого процесса может быть список управления доступом, 
в котором очень подробно сообщается, какие пользователи имеют к нему доступ 
и какие операции они могут выполнять с этим объектом. Такой подход обеспечи¬ 
вает высокую степень детализации настроек параметров безопасности, в которых 
можно разрешить или запретить определенный тип доступа к каждому объекту для 
индивидуальных пользователей или групп. 

Процессы, потоки, синхронизация, управление памятью, файловый ввод-вы¬ 
вод и вызовы безопасности не являются чем-то новым. У других операционных 
систем также есть подобные вызовы, хотя, как правило, их количество исчисляет¬ 
ся не сотнями, как в \Ѵіп32. Но что действительно отличает интерфейс \Ѵіп32 — 
это тысячи и тысячи вызовов для графического интерфейса пользователя. Есть 
вызовы для создания, удаления, управления и использования окон, меню, инстру¬ 
ментальных панелей, строк текущего состояния, линеек прокрутки, диалоговых 
окон, значков и многих других объектов, появляющихся на экране. Существуют 
вызовы для рисования геометрических фигур, заполнения их, управления исполь¬ 
зующимися ими цветовыми палитрами, управления шрифтами и для вывода гра¬ 
фических изображений на экран. Наконец, есть вызовы для работы с клавиатурой, 
мышью и другими устройствами ввода, а также устройствами вывода, такими как 
звуковая карта, принтер и т. д. Короче говоря, интерфейс \Ѵіп32 АРІ (особенно его 
часть, относящаяся к графическому интерфейсу пользователя) огромен, и мы не 
смогли бы даже начать его подробное описание в данной главе, поэтому мы и пы¬ 
таться не будем. Заинтересованные читатели могут обратиться к одной из много¬ 
численных книг по \Ѵіп32 (например, [265, 303, 271]). 

Хотя интерфейс \Ѵіп32 АРІ также присутствует в системе \Ѵіпбоѵѵ5 98 (и в опе¬ 
рационной системе для компактных мобильных компьютеров \Ѵіпбо\Ѵ5 СЕ), не во 
всех версиях \Утбо\Ѵ5 реализован каждый вызов, кроме того, иногда встречают¬ 
ся несущественные различия. Например, в системе \Ѵтбо\Ѵ5 98 нет средств без¬ 
опасности, поэтому вызовы АРІ, относящиеся к ней, просто возвращают в этой 
системе код ошибки. Для имен файлов в \Ѵіпбо\Ѵ5 2000 используется кодировка 
Ипісосіе, недоступная в "ѴѴіпбоѵѵз 98, а в именах файлов системы ЛѴііісіоѵ/з 98, в от¬ 
личие от имен файлов \Ѵіпбо\Ѵ5 2000, не различаются строчные и прописные 
символы (хотя некоторые функции поиска файлов по имени не чувствительны к 
регистру). Кроме того, у некоторых вызовов в различных версиях операционной 
системы \Ѵіп(Іо\Ѵ5 могут различаться входные и выходные параметры. Например, 
в системе \Ѵ1пс1о\ѵ5 2000 все экранные координаты, задаваемые в качестве пара¬ 
метров графическим функциям, представляют собой действительно 32-разрядные 
числа, тогда как в \Ѵіпбо\Ѵ5 98 используются только младшие 16 разрядов, так как 
большая часть графической подсистемы все еще остается 16-разрядной. Суще¬ 
ствование интерфейса \Ѵіп32 АРІ на нескольких различных операционных систем 
облегчает перенос программ с одной системы на другую, но благодаря наличию 
этих небольших различий требуется определенная аккуратность, чтобы програм¬ 
ма оставалась переносимой. 
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Реестр 

Операционной системе Ѵ/ігкіочѵх приходится управлять большими объемами ин¬ 
формации об оборудовании, программном обеспечении и пользователях. В \Ѵіп- 
<іо\ѵ$ 3.x эта информация хранилась в сотнях файлов с расширением .іпі (іпіііаіі- 
гаііоп — инициализация), разбросанных по всему диску. Начиная с \Ѵіпс1о\ѵ5 95, 
почти вся информация, необходимая для загрузки и конфигурирования системы 
и настройки ее под конкретного пользователя, была собрана в одной большой 
центральной базе данных, называемой реестром. В данном разделе будет описан 
реестр \Ѵіпс1о\ѵ5 2000. 

Для начала отметим, что хотя многие части системы \Ѵіпс1о\Ѵ5 2000 сложны и за¬ 
путанны, реестр является одним из самых запутанных мест в \Ѵіпсіо\ѵх, и похожие 
на шифр условные обозначения отнюдь не помогают в нем разобраться. К счастью, 
этой теме были посвящены целые книги [39, 154, 164]. Сама же идея реестра очень 
проста. Он состоит из набора каталогов, каждый из которых содержит либо под¬ 
каталоги, либо записи. В этом он похож на файловую систему, содержащую 
очень маленькие файлы. 

Путаница начинается с того факта, что корпорация МісгозоЙ называет каталог 
реестра ключом, чем он определенно не является. Более того, все каталоги верхне¬ 
го уровня начинаются со строки НКЕУ, что означает «дескриптор ключа». У под¬ 
каталогов, как правило, лучшие имена, хотя и не всегда. 

В нижней части этой иерархической структуры располагаются записи, на¬ 
зываемые значениями, содержащие информацию. У каждого значения три части: 
имя, тип и данные. Имя представляет собой просто строку формата Ипісосіе, ча¬ 
сто сіе^аиі Б, если каталог содержит всего одно значение. Тип может быть одним 
из И стандартных типов. Среди наиболее часто используемых типов строка 
формата Ипісосіе, 32-разрядное целое число, двоичное число произвольной дли¬ 
ны и символьная ссылка на каталог или запись реестра. Символьные имена 
полностью аналогичны символьным ссылкам в файловых системах или значкам 
на рабочем столе \Ѵіпс1о\ѵ5: они позволяют одной записи указывать на другую 
запись или каталог. Символьная ссылка также может использоваться как ключ, 
то есть то, что кажется каталогом, может на самом деле оказаться ссылкой на дру¬ 
гой каталог. 

На верхнем уровне в реестре \Ѵіпс1о\У5 2000 есть шесть ключей, называемых 
корневыми ключами, перечисленные в табл. 11.4. В этой таблице также показаны 
некоторые интересные подключи (подкаталоги). (Применение заглавных букв 
специального значения не имеет, но такова традиция корпорации МісгозоЙ.) Уви¬ 
деть этот список на своей системе можно с помощью одного из редакторов реест¬ 
ра, ге^есііі или ге§есИі32, которые, к сожалению, отображают различную информа¬ 
цию и используют различные форматы. С их помощью можно также изменять 
значения записей реестра. Начинающим пользователям не рекомендуется изме¬ 
нять какие-либо ключи или значения системного реестра, если они хотят впослед¬ 
ствии еще хотя бы раз загрузить эту систему. Однако просмотр реестра не грозит 
никакими последствиями. Итак, я вас предупредил. 
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Таблица 11.4. Корневые ключи и некоторые подключи реестра 

Ключ Описание 


НКЕѴ_ЮСАІ-_МАСНІМЕ 

НАНОѴѴАНЕ 

ЗАМ 

ЗЕСІІРІТУ 

ЗОРТѴѴАРЕ 

ЗУЗТЕМ 

НКЕѴ.ІІЗЕНЗ 

УЗЕР-АЗТ-Ю 

АррЕѵепІз 

Сопзоіе 

Сопігоі 

РапеІ 

Епѵігоптепі 
КеуЬоагс) І_ауоШ 
Ргіпіегз 
ЗоПѵѵаге 

НКЕУ_РЕРРОРМАМСЕ_ОАТА 

НКЕУ_СЬАЗЗЕЗ_РООТ 

НКЕѴ_СІІННЕМТ_СОМРІС 

нкЕУ_сиррЕыт_изЕР 


Свойства аппаратного и программного обеспечения 
Описание аппаратуры и отображение аппаратуры на драйверы 
Информация об учетных записях и правах доступа пользователей 
Политика безопасности для всей системы 
Общая информация об установленных прикладных программах 
Информация для загрузки системы 

Информация о пользователях; по одному ключу на пользователя 
Профиль пользователя АЗТ 

Какой звук, когда издавать (входящая электронная почта/факс, 
ошибка и т. д.) 

Установки командного режима (цвета, шрифты, история и т. д.) 
Внешний вид рабочего стола, заставка, чувствительность 
мыши и т. д. 

Переменные окружения 

Раскладка клавиатуры: 102-кеу 1(3, АГЕНТУ, йѵогак и т. д. 
Информация об установленных принтерах 
Настройки пользователя для программного обеспечения 
корпорации МісгозоП и других производителей 
Сотни счетчиков, следящих за производительностью системы 
Ссылка на НКЕУ_ЮСАІ_МАСНІМЕ\ЗОГГѴѴАНЕ\СЬАЗЗЕЗ 
Ссылка на текущий профиль аппаратного обеспечения 
Ссылка на текущий профиль пользователя 


Первый ключ (то есть каталог), НКЕѴ_ЮСАІ._МАСН]Ж, является, вероятно, наи¬ 
более важным, так как в нем содержится вся информация о локальной системе. 
У этого ключа есть пять подключей (подкаталогов). Подключ НАКОИАКЕ содержит 
множество подключей, в которых хранится вся информация об аппаратном обеспе¬ 
чении, например, какой драйвер какой частью аппаратуры управляет. Эта инфор¬ 
мация формируется на лету менеджером устройств р1и§-ап<і-р]ау во время загруз¬ 
ки системы. В отличие от других подключей этот подключ не хранится на диске. 

Подключ $АМ (Зесигііу Ассоипі Мапа§ег — администратор учетных данных 
в системе безопасности) хранит имена пользователей, групп, пароли, а также дру¬ 
гую информацию об учетных записях пользователей, необходимую для регистра¬ 
ции в системе. Подключ 5ЕСІШТѴ содержит данные об общей политике безопасно¬ 
сти, например минимальную длину паролей, допустимое количество неудачных 
попыток регистрации и т. д. 

Подключ 50РТМКЕ — это то место, в котором производители программного обес¬ 
печения хранят настройки программ. Если у пользователя в системе установлены 
программы АстЬаІ, Ркоіозкор и Ргетіеге компании АсІоЪе, там будет содержаться 
подключ АсІоЬе, под которым будут располагаться подключи для хранения АсгоЬаі:, 
РНоЪозНор, Ргетіеге и других программных продуктов компании АйоЪе. Записи 
в этих подкаталогах могут хранить все, что программистам компании АйоЪе пона¬ 
добится поместить туда, — это номера версии и сборки, а также параметры уста- 
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новки пакета, сведения о драйверах и т. д. Наличие системного реестра избавляет 
их от хлопот по выдумыванию собственного метода хранения подобной информа¬ 
ции. Специфическая для отдельных пользователей информация также хранится 
в реестре, но в ключе НКЕУ_ІІ8ЕК8. 

Подключ 5У5ТЕМ содержит главным образом информацию о загрузке системы, 
например список драйверов, которые требуется загрузить. Здесь также хранится 
список служб (демонов), которые должны быть запущены после загрузки, и све¬ 
дения об их конфигурации. 

Ключ верхнего уровня НКЕѴ_1)$ЕК$ содержит профили для каждого пользовате¬ 
ля. Все выбираемые пользователем настройки и параметры хранятся здесь. Когда 
пользователь изменяет какой-либо параметр при помощи панели управления, ска¬ 
жем, цветовую схему рабочего стола, новые установки записываются сюда. Мно¬ 
гие программы в панели управления главным образом занимаются сбором инфор¬ 
мации, получая ее от пользователя, и сохраняют полученные сведения в реестре. 
Некоторые из подключей ключа НКЕУ_1)5ЕК5 показаны в табл. 11.4 и практически не 
требуют дополнительных комментариев. Другие подключи, например ЗоНмаге, 
содержат удивительно большое количество подключей, даже если в системе не 
установлено никаких пакетов программного обеспечения. 

Ключ верхнего уровня НКЕУ_РЕКРОКМАМСЕ_ОАТА не содержит ни данных, считывае¬ 
мых с диска, ни данных, собираемых менеджером р1и§-апсі-р1ау. Вместо этого дан¬ 
ный ключ предоставляет окно в операционную систему. Сама система содержит 
сотни счетчиков для мониторинга производительности системы. К таким счетчи¬ 
кам можно получить доступ через этот ключ реестра. При обращении к подключу 
запускается специальная процедура, собирающая и возвращающая информацию 
(возможно, считывающая один или несколько счетчиков и объединяющая их 
определенным способом). В редакторах ге§екк или ге§екк32 этот ключ не виден. 
Вместо редактора нужно воспользоваться одной из утилит измерения произво¬ 
дительности, таких как р/топ, рег/топ и рѵіет. Существует множество подобных 
программ, они либо поставляются на компакт-диске \Ѵіпс1оѵг5 2000, либо входят 
в пакет Кезоигсе КіГ, либо производятся другими компаниями. 

Остальных трех ключей верхнего уровня на самом деле не существует. Каж¬ 
дый из них представляет собой символьную ссылку на определенный подключ 
реестра. Самым интересным является ключ НКЕѴ_СІ_А55Е5_К00Т. Он указывает на ката¬ 
лог, управляющий объектами СОМ (Сотропепі ОЬ]есТ Мосіеі — модель компонент¬ 
ных объектов), а также занимающийся установкой соответствий между расшире¬ 
ниями файлов и программами. Когда пользователь дважды щелкает мышью на 
файле, имя которого оканчивается на, скажем, .кос, программа, перехватывающая 
щелчок мыши, смотрит в это место реестра, чтобы определить, которую програм¬ 
му следует запустить (вероятно, Місгозо/і \ѴопІ). Ключ НКЕѴ_СІ_А55Е5_К00Т содержит 
целую базу данных распознаваемых расширений и соответствующих им программ. 

Ключ НКЕУ СикКЕНТ СОЫРІб представляет собой ссылку на подключ, содержащий 
информацию о текущей конфигурации аппаратного обеспечения. Пользователь 
может сформировать несколько конфигураций аппаратуры, например, отключая 
различные устройства, чтобы проверить, не они ли служили причиной странно¬ 
го поведения системы. Этот ключ указывает на текущую конфигурацию. Ключ 
НКЕѴ_СІ)ККЕМТ_и$ЕК указывает на настройки текущего пользователя, что позволяет 
быстро находить их. 
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Ни один из последних трех ключей в действительности ничего не добавляет, 
так как эта информация уже была доступна (хотя и не в столь удобном виде). 
Таким образом, хотя редакторы ге§есЛс и ге@е3іс32 перечисляют пять ключей верх¬ 
него уровня, на самом деле существуют только три каталога верхнего уровня, один 
из которых не отображается. 

Реестр полностью доступен программисту \Ѵіп32. Существуют вызовы для со¬ 
здания и удаления ключей, просмотра значений ключей и т. д. Некоторые наибо¬ 
лее важные вызовы перечислены в табл. 11.5. 


Таблица 11.5. Некоторые вызовы \Л/іп32 АРІ для работы с реестром 


Функция ѴѴіп32 АРІ Описание 


ВедСгеаіеКеуЕх 

РедОеІеіеКеу 

РедОрепКеуЕх 

РедЕпитКеуЕх 

РедОиегуѴаІиеЕх 


Создать новый ключ реестра 

Удалить ключ реестра 

Открыть ключ и получить его дескриптор 

Перенумеровать подключи, подчиненные ключу дескриптора 

Искать данные по значению в ключе 


Когда система выключается, большая часть данных реестра (но не вся, как уже 
упоминалось выше) сохраняется на диске в файлах, называемых ульями. Большин¬ 
ство этих файлов располагается в каталоге \тппС\5у5Сет32\соп/і§. Поскольку их 
целостность представляет особую важность для правильной работы системы, при 
их обновлении автоматически создаются резервные копии, а запись выполняется 
при помощи атомарных транзакций, чтобы предотвратить порчу данных в случае 
сбоя системы во время записи. При потере реестра потребуется переустанавливать 
все программное обеспечение. 


Структура системы 

В предыдущих разделах мы рассмотрели \Ѵіпбо\ѵ5 2000 с точки зрения программи¬ 
ста. Теперь мы откроем капот и посмотрим, как устроена система внутри, что дела¬ 
ют ее различные компоненты, как они взаимодействуют друг с другом и с програм¬ 
мами пользователя. Хотя использованию операционной системы \Ѵіпс1о\ѵз 2000 
посвящено множество книг, далеко не все они рассказывают о том, как работает 
эта система. Без сомнения, лучшим источником, в котором можно получить допол¬ 
нительную информацию по этому вопросу, является [309]. В основе некоторой час¬ 
ти материала данной главы лежит эта книга и сведения, полученные от ее авторов. 
Корпорация МісгозоЙ также относится к основным источникам. 

Структура операционной системы 

Операционная система \Ѵіпс1о\ѵ5 2000 состоит из двух основных частей: самой опе¬ 
рационной системы, работающей в режиме ядра, и подсистем окружения, работа¬ 
ющих в режиме пользователя. Ядро является традиционным ядром в том смысле, 
что оно управляет процессами, памятью, файловой системой и т. д. Подсистемы 
окружения представляют собой нечто необычное, так как они являются отдель- 
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ными процессами, помогающими пользователю выполнять определенные систем¬ 
ные функции. В следующих разделах мы по очереди изучим обе части системы. 

Одно из многих усовершенствований системы N7 по сравнению с \Ѵіпбо\ѵз 3.1 
заключалось в ее модульной структуре. Она состояла из относительно небольшо¬ 
го ядра, работавшего в режиме ядра, плюс нескольких серверных процессов, рабо¬ 
тавших в режиме пользователя. Процессы пользователя взаимодействовали с сер¬ 
верными процессами с помощью модели клиент-сервер: клиент посылал серверу 
сообщение, а сервер выполнял определенную работу и возвращал клиенту резуль¬ 
тат в ответном сообщении. Такая модульная структура упрощала перенос систе¬ 
мы на другие компьютеры. В результате операционная система \Ѵіпбо\ѵз >ГГ была 
успешно перенесена на платформы с процессорами, отличными от процессоров 
Іпбеі, а именно: АІрЬа корпорации БЕС, Ро\ѵег РС корпорации ІВМ и МІР5 фир¬ 
мы 5СІ. Кроме того, такая структура защищала ядро от ошибок в коде серверов. 
Однако для увеличения производительности, начиная с версии ИТ 4.0, довольно 
большая часть операционной системы (например, управление системными вызо¬ 
вами и вся экранная графика) были возвращены в ядро. Такая схема сохранилась 
и в \Ѵіпбо\ѵз 2000. 

Тем не менее в операционной системе \Ѵіпс1о\ѵз 2000 сохранилась некоторая 
структура. Система разделена на несколько уровней, каждый из которых пользу¬ 
ется службами лежащего ниже уровня. Эта структура проиллюстрирована на 
рис. 11.2. (Затененная область обозначает исполняющую систему. Квадратики, 
помеченные символом «Б», обозначают драйверы устройств. Сервисные процес¬ 
сы являются системными демонами.) Один из уровней разделен горизонтально на 
множество модулей. У каждого модуля есть определенная функция, а также четко 
определенный интерфейс для взаимодействия с другими модулями. 



Рис. 11.2. Структура ѴѴіпсІоѵѵз 2000 (слегка упрощенная) 
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Два нижних уровня программного обеспечения, уровень аппаратных абстрак¬ 
ций (НАЬ, Нагбшаге АЪзігасГіоп Ьауег) и ядро написаны на языке С и ассемблере 
и являются частично машинно-зависимыми. Верхние уровни написаны исключи¬ 
тельно на С и почти полностью машинно-независимы. Драйверы написаны на С 
или, в некоторых случаях, на С++. В последующих разделах мы изучим различ¬ 
ные компоненты системы, начиная с самых нижних уровней и постепенно продви¬ 
гаясь наверх. 

Уровень аппаратных абстракций 

Одна из целей создания \Уіпс1о\ѵз 2000 (и \Уіпс1о\ѵз N7) заключалась в возмож¬ 
ности переносить систему на другие платформы. В идеале при появлении новой 
машины для запуска операционной системы на ней нужно всего лишь переком¬ 
пилировать операционную систему новым компилятором для данной машины. 
К сожалению, жизнь не так легка. Хотя можно добиться полной переносимости 
верхних уровней операционной системы (так как в основном они имеют дело с внут¬ 
ренними структурами данных), нижние уровни работают с регистрами устройств, 
прерываниями, ОМА и другими аппаратными особенностями, которые очень силь¬ 
но отличаются на разных машинах. Хотя большая часть кода нижнего уровня напи¬ 
сана на С, даже ее нельзя просто перенести с процессора РепСіиш на процессор 
АІрЬа, перекомпилировать и перезагрузить, так как существует большое количе¬ 
ство мелких различий между этими процессорами, не имеющих отношения к раз¬ 
личиям в наборе команд, которые невозможно спрятать компилятором. 

Ясно представляя себе эту проблему, корпорация МісгозоЙ предприняла серьез¬ 
ные попытки скрыть многие из аппаратных различий в тонком уровне на самом дне 
системы, названном уровнем аппаратных абстракций (НАЬ, НагсКѵаге АЬзІгасІіоп 
Ьауег). (Без всякого сомнения, имя НАЬ было позаимствовано у компьютера НАЬ 
в фильме Стэнли Кубрика «2001: Космическая Одиссея ». По слухам, Кубрик по¬ 
лучил название своего компьютера из имени доминирующей в то время компью¬ 
терной корпорации ІВМ, в результате вычитания единицы из каждой буквы.) 

Работа уровня НАЬ заключается в том, чтобы предоставлять всей остальной 
системе абстрактные аппаратные устройства, свободные от бородавок и индиви¬ 
дуальных отличительных особенностей, которыми так богато реальное аппарат¬ 
ное обеспечение. Эти устройства представляются в виде машинно-независимых 
служб (процедурных вызовов и макросов), которые могут использоваться осталь¬ 
ной операционной системой и драйверами. Поскольку драйверы и ядро пользуются 
службами НАЬ (идентичными на всех операционных системах \Уіпс1о\уз 2000, не¬ 
зависимо от аппаратного обеспечения) и не обращаются напрямую к устройствам, 
требуется значительно меньше изменений для их переноса на другую платформу. 
Перенос самого уровня НАЬ довольно прост, так как весь машинно-зависимый код 
сконцентрирован в одном месте, а цель переделки четко определена, то есть за¬ 
ключается в реализации всех служб уровня НАЬ. 

В уровень НАЬ включены те службы, которые зависят от набора микросхем 
материнской платы и меняются от машины к машине в разумных предсказуемых 
пределах. Другими словами, он разработан, чтобы скрывать различия между 
материнскими платами различных производителей, но не различия между процес¬ 
сорами Репііиш и АІрЬа. К службам уровня НАЬ относятся: доступ к регистрам 
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устройств, адресация к устройствам, независящим от шины, обработка прерыва¬ 
ний и возврат из прерываний, операции БМА (Оігесі: Метогу Ассезз — прямой 
доступ к памяти), управление таймерами, часами реального времени, спин-бло¬ 
кировками нижнего уровня и синхронизация многопроцессорных конфигура¬ 
ций, интерфейс с ВІОЗ и доступ к СМОЗ-памяти. Уровень НАЬ не предоставляет 
абстракций или служб для специфических устройств ввода-вывода — клавиатур, 
мышей или дисков, а также блоков управления памятью МЛШ. 

В качестве примера того, что делает уровень аппаратных абстракций, рас¬ 
смотрим вопрос устройств ввода-вывода с отображаемыми на память регистрами 
и устройств ввода-вывода, доступ к которым осуществляется через порты. На не¬ 
которых машинах используется один способ доступа к устройствам ввода-выво¬ 
да, а на других машинах — другой. Как должен быть запрограммирован драйвер: 
на использование портов или регистров? Вместо того чтобы заставлять делать вы¬ 
бор в пользу одного или другого метода (что приведет к невозможности переноса 
драйвера с одной платформы на другую), уровень аппаратных абстракций предо¬ 
ставляет три процедуры для чтения регистров устройств и еще три для записи в них: 

ис = РЕА0_Р0РТ_ІІСНАК(рог1:) ; ИКІТЕ_РОКТ_иСНАК(рогТ, ис): 

из = РЕА0_Р0РТ_и5Н0РТ(рогІ); И«ІТЕ_Р0РТ_и5Н0РТ(рогТ. из): 

иі = КЕА0_Р0КТ_1Ъ(Ж(рогТ); МРІТЕ_Р0РТ_І_(Шрог1;. иі): 

Эти процедуры читают и пишут соответственно 8-, 16- и 32-разрядные целые 
без знака числа в указанный порт. Реализацией этих действий в виде обращения 
к физическим портам или регистрам, отображаемым на память, занимается уровень 
НАЬ. Таким образом, драйвер без каких-либо изменений может быть перемещен 
на совершенно иную платформу. 

Драйверам часто бывает нужно получить доступ к специфическим устройствам 
ввода-вывода. На аппаратном уровне у драйвера есть один или несколько адресов 
определенной шины. Поскольку у современных компьютеров часто есть несколь¬ 
ко шин (ІЗА, РСІ, ЗСЗІ, ЫЗВ, 1394 и т. д.), может случиться, что два или более 
устройств имеют один и тот же адрес шины, поэтому требуется некоторый способ 
отличать эти устройства. Уровень НАЬ предоставляет службу для идентифика¬ 
ции устройств, отображая адреса устройств на шине на логические системные 
адреса. Поэтому драйверам не нужно следить за тем, которое устройство находит¬ 
ся на какой шине. Такая логическая адресация аналогична дескрипторам, выдава¬ 
емым операционной системой программам пользователя для обращения к файлам 
и другим системным ресурсам. Этот механизм также защищает более высокие 
уровни от свойств структур шин и соглашений об адресации. 

С прерываниями связана схожая проблема — они также являются зависимыми 
от шины. Здесь уровень НАЬ предоставляет службы для именования прерываний 
уникальным в пределах всей системы способом, а также службы, позволяющие 
драйверам связывать процедуры обработки прерываний с прерываниями перено¬ 
симым способом. При этом не нужно знать, какой вектор к какой шине относится. 
Управление уровнем запроса прерывания также осуществляется на уровне НАЬ. 

Другая служба НАЬ занимается управлением операциями ЭМА независимым 
от устройств способом. НАЬ может управлять как единым для всей системы меха¬ 
низмом ЭМА, так и механизмами ЭМА, специфичными для конкретных плат вво¬ 
да-вывода. Обращение к устройствам осуществляется по их логическим адресам. 
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Уровень НАЬ также реализует программные операции чтения/записи с разнесе¬ 
нием данных (с обращением к не являющимся соседними блокам памяти). 

Уровень НАЬ управляет часами и таймерами, обеспечивая переносимость 
работающих с ними программ. Время хранится в интервалах по 100 нс, начиная 
с 1 января 1601 года, что существенно точнее, чем то, как это делалось в МЗ-БОЗ 
(в 2-секундных интервалах с 1 января 1980 года). К тому же новый способ хра¬ 
нения времени позволяет учитывать относящуюся к компьютерам деятельность 
в XVII—XIX веках. Временные службы уровня НАЬ обеспечивают независимость 
драйверов от фактических частот, на которых работают часы. 

Иногда требуется синхронизация компонентов ядра на очень низком уровне, 
особенно для того, чтобы избежать конфликтов на многопроцессорных системах. 
Уровень НАЬ предоставляет несколько примитивов для управления этой синхро¬ 
низацией. Примером являются спин-блокировки, в которых один центральный 
процессор просто ждет, пока другой центральный процессор не освободит опреде¬ 
ленный ресурс. В частности, такой метод синхронизации применяется в ситуаци¬ 
ях, в которых доступ к ресурсу, как правило, получается всего на несколько ко¬ 
манд процессора. 

Наконец, после загрузки операционной системы уровень НАЬ общается с ВІ08 
и инспектирует память конфигурации СМ08, если она используется, чтобы 
определить, какие шины и устройства ввода-вывода содержатся в системе и как 
их следует настроить. Затем эта информация помещается в реестр, чтобы другие 
компоненты системы могли просматривать их, не обращаясь напрямую к ВЮЗ 
или СМОЗ-памяти. Схематично набор функций, выполняемый уровнем НАЬ, по¬ 
казан на рис. 11.3. 


Регистры Адреса Прерывания ОМА Таймеры Спин- ВЮЗ 

устройств устройств блокировка 



Рис. 11.3. Некоторые функции уровня НАЬ 

Поскольку уровень НАЬ является в большой степени машинно-зависимым, он 
должен в совершенстве соответствовать системе, на которой установлен, поэтому 
набор различных уровней НАЬ поставляется на компакт-диске \ѴіпсІо\ѵз 2000. 
Во время установки системы из них выбирается подходящий уровень и копируется 
на жесткий диск в системный каталог \тпп(\зу5(ет32 в виде файла НаЫІІ. При всех 
последующих загрузках операционной системы используется эта версия уровня 
НАЬ. Если удалить этот файл, то система загрузиться не сможет. 
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Хотя эффективность уровня НАЬ является довольно высокой, для мульти¬ 
медийных приложений ее может быть недостаточно. По этой причине корпора¬ 
ция МісгозоЙ также производит пакет программного обеспечения, называемый 
ОігесіХ, расширяющий функциональность уровня НАЬ дополнительными про¬ 
цедурами и предоставляющий пользовательским процессам прямой доступ к ап¬ 
паратному обеспечению. Пакет ОігесіХ является специализированным, поэтому 
мы не станем обсуждать его в дальнейшем в данной главе. 

Уровень ядра 

Над уровнем аппаратных абстракций располагается уровень, содержащий то, что 
корпорация МісгозоФ называет ядром, а также драйверы устройств. В некоторых 
старых документах ядро называлось «микроядром», которым оно никогда не было, 
так как менеджер памяти, файловая система и другие основные компоненты систе¬ 
мы постоянно находились в пространстве ядра и с самого начала работали в режиме 
ядра. Ядро определенно не является микроядром и сейчас, так как, начиная с ИТ 4.0, 
практически вся операционная система была помещена в пространство ядра. 

В главе, посвященной операционной системе ЫШХ, мы использовали термин 
«ядро» для обозначения всего, что работает в режиме ядра. В данной главе мы 
(весьма неохотно) зарезервируем этот термин для обозначения части системы на 
рис. 11.2, помеченной этим словом, а все программное обеспечение, работающее в 
режиме ядра, станем называть «операционной системой». Часть ядра (и большая 
часть уровня НАЬ) постоянно находится в оперативной памяти (то есть не выгру¬ 
жается). При помощи установки соответствующего приоритета эта часть ядра 
может решать, допустимо ли прерывание от устройств ввода-вывода или нет. 
Хотя значительная часть ядра представляет собой машинно-зависимую програм¬ 
му, тем не менее большая ее часть написана на С, кроме тех мест, в которых произ¬ 
водительность считается важнее всех остальных задач. 

Назначение ядра заключается в том, чтобы сделать всю остальную часть опера¬ 
ционной системы независимой от аппаратуры и, таким образом, легко переноси¬ 
мой на другие платформы. Оно начинается там, где заканчивается уровень НАЬ. 
Ядро получает доступ к аппаратуре через уровень НАЬ. Оно построено на чрезвы¬ 
чайно низкоуровневых службах уровня НАЬ, формируя из них абстракции более 
высоких уровней. Например, у уровня НАЬ есть вызовы для связывания процедур 
обработки прерываний с прерываниями и установки их приоритетов, но больше 
практически ничего уровень НАЬ в этой области не делает. Ядро, напротив, предо¬ 
ставляет полный механизм для переключения контекста. Оно должным образом 
сохраняет все регистры центрального процессора, изменяет таблицы страниц, со¬ 
храняет кэш центрального процессора и т. д. Когда все эти действия выполнены, 
работавший ранее поток оказывается полностью сохраненным в таблицах, распо¬ 
ложенных в памяти. Затем ядро настраивает карту памяти нового потока и загру¬ 
жает его регистры, после чего новый поток готов к работе. 

Программа планирования потоков также располагается в ядре. Когда насту¬ 
пает пора проверить, не готов ли к работе новый поток, например, после того, как 
истечет выделенный потоку квант времени или по завершении процедуры обработ¬ 
ки прерываний ввода-вывода, ядро выбирает поток и выполняет переключение 
контекста, необходимое, чтобы запустить этот поток. С точки зрения остальной 
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операционной системы, переключение потоков автоматически осуществляется 
более низкими уровнями, так что для более высоких уровней не остается никакой 
работы. Сам алгоритм планирования будет обсуждаться ниже в этой главе, когда 
мы подойдем к теме процессов и потоков. 

Помимо предоставления абстрактной модели аппаратуры более высоким 
уровням и управления переключениями потоков, ядро также выполняет еще одну 
ключевую функцию: предоставляет низкоуровневую поддержку двум классам 
объектов — управляющим объектам и объектам диспетчеризации. Эти объекты не 
являются объектами, к которым пользовательские процессы получают дескрип¬ 
торы, но представляют собой внутренние объекты, на основе которых исполняю¬ 
щая система строит объекты пользователя. 

Управляющие объекты — это объекты, управляющие системой, включая при¬ 
митивные объекты процессов, объекты прерываний и два несколько странных 
объекта, называемых БРС и АРС. Объект БРС (Беіеггесі Ргосесіиге Саіі — отло¬ 
женный вызов процедуры) используется, чтобы отделить часть процедуры обра¬ 
ботки прерываний, для которой время является критичным, от той ее части, для 
которой время некритично. Как правило, процедура обработки прерываний сохра¬ 
няет несколько аппаратных регистров, связанных с прерывающим устройством 
ввода-вывода, чтобы их можно было потом восстановить, и разрешает аппаратуре 
продолжать работу, но оставляет большую часть обработки на потом. 

Например, когда пользователь нажимает на клавишу, процедура обработки 
прерываний от клавиатуры считывает из регистра код нажатой клавиши и разреша¬ 
ет прерывания от клавиатуры. Но эта процедура не должна немедленно обрабаты¬ 
вать введенный символ, особенно если в данный момент происходит нечто более 
важное (то есть нечто с более высоким приоритетом). Пока обработка клавиши за¬ 
нимает не более 100 мс, пользователь ничего не заметит. Отложенные вызовы про¬ 
цедуры также применяются для слежения за таймерами и другой активностью, для 
которой не требуется немедленная обработка. Очередь ЭРС представляет собой 
механизм напоминания о том, что есть работа, которую следует выполнить позднее. 

Объект АРС (АзупсЬгопоиз Ргосесіиге Саіі — асинхронный вызов процедуры) 
похож на отложенный вызов процедуры БРС, но отличается тем, что асинхрон¬ 
ный вызов процедуры выполняется в контексте определенного процесса. Когда 
обрабатывается нажатая клавиша, не имеет значения, в каком контексте работает 
ЭРС, так как все, что требуется сделать, — это исследовать введенный код и, воз¬ 
можно, поместить его в буфер в ядре. Однако если по прерыванию потребуется 
скопировать буфер из пространства ядра в адресное пространство пользовательс¬ 
кого процесса (например, по завершении операции чтения модема), тогда проце¬ 
дура копирования должна работать в контексте получателя. Контекст получателя 
нужен для того, чтобы в таблице страниц одновременно содержались и буфер ядра, 
и буфер пользователя (все процессы, как мы увидим в дальнейшем, содержат в сво¬ 
ем адресном пространстве все ядро целиком). По этой причине в разных ситуаци¬ 
ях используются АРС или БРС. 

Еще один тип объектов ядра — объекты диспетчеризации. К ним относятся 
семафоры, мьютексы, события, таймеры и другие объекты, изменения состояния 
которых могут ждать потоки. Причина, по которой они должны (частично) обра¬ 
батываться ядром, заключается в том, что они тесно переплетены с планированием 
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потоками, что входит в круг задач ядра. Кстати, мьютексы в программах назывались 
«мутантами», так как от них требовалось соблюдение семантики операционной 
системы 03/2. То есть они не должны были автоматически разблокироваться, 
когда процесс, захвативший их, прекращал свою работу. Такое поведение разра¬ 
ботчики \Ѵіпс1о\уз 2000 посчитали странным. (Семантика 03/2 использовалась, 
потому что изначально предполагалось, что КТ заменит эту операционную систе¬ 
му, поставлявшуюся с компьютерами РС/2 корпорации ІВМ.) 

Исполняющая система 

Над ядром и драйверами устройств располагается верхняя часть операционной 
системы, называемая исполняющей системой (а также иногда супервизором или 
диспетчером), показанная в виде затененной области на рис. 11.2. Исполняющая 
система написана на С, она не зависит от архитектуры и может быть перенесена 
на новые машины с относительно небольшими усилиями. Исполняющая система 
состоит из 10 компонентов, каждый из которых представляет собой просто набор 
процедур, работающих вместе для выполнения некоторой задачи. Между отдель¬ 
ными компонентами нет жестких границ, и различные авторы, описывающие ис¬ 
полняющую систему, могут даже по-разному группировать составляющие ее про¬ 
цедуры в компоненты. Следует заметить, что компоненты одного уровня могут 
вызывать друг друга, и на практике они этим довольно активно занимаются. 

Менеджер объектов управляет всеми объектами, известными операционной 
системе. К ним относятся процессы, потоки, файлы, каталоги, семафоры, устрой¬ 
ства ввода-вывода, таймеры и многое другое. При создании объекта менеджер 
объектов получает в адресном пространстве ядра блок виртуальной памяти и воз¬ 
вращает этот блок в список свободных блоков, когда объект уничтожается. Его 
работа заключается в том, чтобы следить за всеми объектами. 

Чтобы избежать путаницы, отметим, что большинство компонентов исполня¬ 
ющей системы, помеченные на рис. 11.2 как «менеджеры», не являются процесса¬ 
ми или потоками, а представляют собой просто набор процедур, которые могут 
выполняться другими потоками в режиме ядра. Однако некоторые из них, такие 
как менеджер питания и менеджер р1и§-апсі-р1ау, являются настоящими потоками. 

Менеджер объектов также управляет пространством имен, в которое помеща¬ 
ется созданный объект, чтобы впоследствии к нему можно было обратиться по 
имени. Все остальные компоненты исполняющей системы активно пользуются 
объектами во время своей работы. Объекты занимают центральное место в функ¬ 
ционировании операционной системы \Ѵіп<іо\У5 2000, поэтому они будут подроб¬ 
но обсуждаться в следующем разделе. 

Менеджер ввода-вывода формирует каркас для управления устройствами 
ввода-вывода и предоставляет общие службы ввода-вывода. Он предоставляет 
остальной части системы независимый от устройств ввод-вывод, вызывая для 
выполнения физического ввода-вывода соответствующий драйвер. Здесь также 
располагаются все драйверы устройств (обозначены символом «Б» на рис. 11.2). 
Файловые системы формально являются драйверами устройств под управлением 
менеджера ввода-вывода. Существует два драйвера для файловых систем РАТ 
и КТРЗ, независимые друг от друга и управляющие различными разделами диска. 
Все файловые системы РАТ управляются одним драйвером. Ввод-вывод мы рас- 
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смотрим в разделе «Ввод-вывод в \Ѵіпс1о\ѵ5 2000», а одну из файловых систем, 
ЭТТ5 — в разделе «Файловая система \Ѵіпс1о\ѵ5 2000». 

Менеджер процессов управляет процессами и потоками, включая их созда¬ 
ние и завершение. Он занимается не стратегиями, применяемыми по отношению 
к процессам, а механизмом, используемым для управления ими. Менеджер про¬ 
цессов основывается на объектах потоков и процессов ядра и добавляет к ним до¬ 
полнительные функции. Это ключевой элемент многозадачности в \Ѵіпс1о\ѵз 2000. 
Управление процессами будет рассматриваться в разделе «Процессы и потоки 
в\Ѵіпс1о\ѵ5 2000». 

Менеджер памяти реализует архитектуру виртуальной памяти со страничной 
подкачкой по требованию операционной системы \Ѵіпс1о\ѵз 2000. Он управляет 
преобразованием виртуальных страниц в физические страничные блоки. Таким- 
образом, он реализует правила защиты, ограничивающие доступ каждого про¬ 
цесса только теми страницами, которые принадлежат его адресному пространству, 
а не адресным пространствам других процессов (кроме специальных случаев). 
Он также контролирует определенные системные вызовы, относящиеся к вирту¬ 
альной памяти. Управление памятью будет рассматриваться в разделе «Управле¬ 
ние памятью». 

Менеджер безопасности приводит в исполнение сложный механизм без¬ 
опасности \Ѵіпс1о\ѵ5 2000, удовлетворяющий требованиям класса С2 Оранжевой 
книги Министерства обороны США. В Оранжевой книге перечислено множество 
правил, которые должна соблюдать система, начиная с аутентификации при реги¬ 
страции и заканчивая управлением доступом, а также обнулением страниц перед 
их повторным использованием. Менеджер безопасности будет обсуждаться в раз¬ 
деле «Безопасность в \Ѵіпс1оѵг5 2000». 

Менеджер кэша хранит в памяти блоки диска, которые использовались в по¬ 
следнее время, чтобы ускорить доступ к ним в случае, если они понадобятся вновь. 
Его работа состоит в том, чтобы определить, какие блоки понадобятся снова, а ка¬ 
кие нет. Операционная система \Ѵіпс1о\ѵз 2000 может одновременно использовать 
несколько файловых систем. В этом случае менеджер кэша обслуживает все фай¬ 
ловые системы, таким образом, каждой файловой системе не нужно заниматься 
управлением собственного кэша. Когда требуется блок, он запрашивается у менед¬ 
жера кэша. Если у менеджера кэша нет блока, он обращается за блоком к соответ¬ 
ствующей файловой системе. Поскольку файлы могут отображаться в адресное 
пространство процессов, менеджер кэша должен взаимодействовать с менеджером 
виртуальной памяти, чтобы обеспечить требуемую непротиворечивость. Количе¬ 
ство памяти, выделенной для кэша, динамически изменяется и может увеличивать¬ 
ся или уменьшаться при необходимости. Менеджер кэша будет описан в разделе 
«Кэширование в \Ѵіпс1о\ѵ5 2000». 

Менеджер рІи§-апсІ-рІау получает все уведомления об установленных новых 
устройствах. Для некоторых устройств проверка производится при загрузке сис¬ 
темы, но не после нее. Другие устройства, например устройства ИЗБ (ІІпіѵегзаІ 
Зегіаі Виз — универсальная последовательная шина), могут подключаться в лю¬ 
бое время, и их подключение запускает пересылку сообщения менеджеру р1и§-апс1- 
ріау, который затем находит и загружает соответствующий драйвер. 
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Менеджер энергопотребления управляет потреблением электроэнергии. Он 
выключает монитор и диски, если к ним не было обращений в течение определен¬ 
ного интервала времени. На переносных компьютерах менеджер энергопотребле¬ 
ния следит за состоянием батарей и, когда заряд батарей подходит к концу, пред¬ 
принимает соответствующие действия. Эти действия, как правило, заключаются 
в том, что он сообщает работающим программам о состоянии батарей. В результа¬ 
те программы могут сохранить свои файлы и приготовиться к корректному завер¬ 
шению работы. 

Менеджер конфигурации отвечает за состояние реестра. Он добавляет новые 
записи и ищет запрашиваемые ключи. 

Менеджер вызова локальной процедуры обеспечивает высокоэффективное 
взаимодействие между процессами и их подсистемами. Поскольку этот путь ну¬ 
жен для выполнения некоторых системных вызовов, эффективность оказывается 
критичной, вот почему для этого не используются стандартные механизмы меж¬ 
процессного взаимодействия. 

Исполняющий модуль '\Ѵіп32 ОИІ обрабатывает определенные системные 
вызовы (но не все). Изначально он располагался в пространстве пользователя, но 
в версии ЫТ 4.0 для увеличения производительности был перенесен в простран¬ 
ство ядра. Интерфейс графических устройств СИІ (СгарЬіс Эеѵісе ІпіеИасе) за¬ 
нимается управлением графическими изображениями для монитора и принтеров. 
Он предоставляет системные вызовы, позволяющие пользовательским програм¬ 
мам выводить данные на монитор и принтеры независящим от устройств спосо¬ 
бом. Он также содержит оконный менеджер и драйвер дисплея. До версии ЫТ 4.0 
интерфейс графических устройств также находился в пространстве пользователя, 
но производительность при этом оставляла желать лучшего, поэтому корпорация 
МісгозоЛ переместила его в ядро. Следует отметить, что рис. 11.2 создан безо всяко¬ 
го соблюдения масштаба. Так, например, интерфейс '\Ѵіп32 и модуль СБІ, вместе 
взятые, превосходят всю остальную исполняющую систему. 

Над исполняющей системой размещается тонкий уровень, называемый систем¬ 
ными службами. Его функции заключаются в предоставлении интерфейса к ис¬ 
полняющей системе. Он принимает настоящие системные вызовы ^іпсіоѵѵз 2000 
и вызывает другие части исполняющей системы для их выполнения. 

При загрузке операционная система \ѴіпсІо\ѵ$ 2000 загружается в память как 
набор файлов. Основная часть операционной системы, состоящая из ядра и ис¬ 
полняющей системы, хранится в файле піозкті.ехе. Уровень НАЬ представляет 
собой библиотеку общего доступа, расположенную в отдельном файле каЫІІ. 
Интерфейс ^іп32 и интерфейс графических устройств хранятся вместе в тре¬ 
тьем файле, тп32к.зуз. Наконец, загружается множество драйверов устройств. 
У большинства из них расширение .зуз. 

На самом деле все не совсем так просто. Существует две версии файла піозкті.ехе'. 
для однопроцессорных и многопроцессорных систем. Кроме того, существуют 
версии для процессора Хеоп, способного поддерживать более 4 Гбайт физичес¬ 
кой памяти, и для процессора Репііит, который так много оперативной памяти 
поддержать не может. Наконец, этот модуль может содержать или не содержать 
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отладочные функции, в зависимости от чего он предназначается либо для отлад¬ 
ки системы, либо для продажи в магазинах. Всего получается восемь комбина¬ 
ций, но две пары были объединены вместе, и в результате остается только шесть. 
Одна из них копируется при установке в файл піозкті.ехе. 

Следует сказать несколько слов об отладочных версиях. Когда на персональ¬ 
ный компьютер устанавливается новое устройство ввода-вывода, то требуется ус¬ 
тановка драйвера, поставляемого производителем устройства, чтобы оно могло 
работать. Предположим, что карта ІЕЕЕ 1394 установлена на компьютере и вроде 
бы нормально работает. Спустя две недели система внезапно рушится. Кого будет 
винить в этом владелец компьютера? Конечно, корпорацию МісгозоК. 

Ошибка, действительно, может произойти по вине корпорации МісгозоК, но на 
самом деле некоторые ошибки бывают в неверно написанных драйверах, которые 
корпорация МісгояоЙ не может контролировать и которые устанавливаются в па¬ 
мять ядра и получают полный доступ к таблицам ядра, а также и ко всему аппа¬ 
ратному обеспечению. Пытаясь уменьшить количество телефонных звонков от 
разгневанных покупателей, корпорация МісгозоК старается помочь авторам драй¬ 
веров отладить их программы при помощи внедрения в различные места этих про¬ 
грамм операторов вида 

А55ЕКТ(некоторое условие) 

Эти операторы проверяют некоторые условия (например, допустимость тех или 
иных параметров). В коммерческой версии операционной системы все операторы 
А88ЕКТ определены как макрос, который ничего не выполняет, таким образом, 
проверка из системы удаляется. В отладочной версии они определены как 

#с!еГі пе А$5ЕКТ(а) іГ (! (а)) еггог( ... ). 

в результате чего все проверки после трансляции ядра системы оказываются в ис¬ 
полняемом коде файла піозкті.ехе и могут выполняться во время работы систе¬ 
мы. Хотя наличие подобных проверок страшно замедляет работу системы, эти про¬ 
верки помогают авторам отладить свои драйверы, прежде чем они будут переданы 
покупателям. В отладочные версии системы также включено множество других 
функций отладки. 

Драйверы устройств 

Последняя часть схемы на рис. 11.2 состоит из драйверов устройств. Каждый 
драйвер может управлять одним или несколькими устройствами ввода-вывода, но 
драйвер устройства может также выполнять действия, не относящиеся к какому- 
либо специфическому устройству — шифровать поток данных или даже просто 
предоставлять доступ к структурам данных ядра. Драйверы устройств не являются 
частью двоичного файла піозкті.ехе. Преимущество такого подхода заключается 
в том, что как только драйвер устанавливается в систему, он добавляется в реестр 
и затем динамически загружается при каждой загрузке системы. Таким образом, 
файл піозкті.ехе остается одинаковым для всех конфигураций систем, но каждая 
система точно настраивается на конфигурацию аппаратуры. 

Существуют драйверы для реально видимых и осязаемых устройств ввода-вы¬ 
вода, таких как диски и принтеры, но также есть драйверы для многих внутренних 
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устройств и микросхем, о которых практически никто ничего не слышал. Кроме 
того, как уже было сказано, файловые системы также представлены в виде драй¬ 
веров устройств. Самый большой драйвер устройства для интерфейса ^іп32 и 
СЭІ показан на правой стороне рис. 11.2. Он обрабатывает множество системных 
вызовов и управляет большей частью графики. Поскольку пользователи могут 
устанавливать новые драйверы, у них есть возможность изменить содержимое ядра 
и повредить систему. По этой причине драйверы следует писать с большой осто¬ 
рожностью. 

Реализация объектов 

Объекты представляют собой, вероятно, самое важное понятие операционной си¬ 
стемы ^іпс1о\ѵ5 2000. Они предоставляют однородный и непротиворечивый ин¬ 
терфейс ко всем системным ресурсам и структурам данных, таким как процессы, 
потоки, семафоры и т. д. У этой однородности есть много граней. Во-первых, все 
объекты именуются по одной и той же схеме. Доступ ко всем объектам также пре¬ 
доставляется одинаково, при помощи дескрипторов объектов. Во-вторых, посколь¬ 
ку доступ к объектам всегда осуществляется через менеджер объектов, все провер¬ 
ки, связанные с защитой, могут быть размещены в одном месте, с гарантией, что 
ни один процесс не сможет обойти их. В-третьих, возможно совместное исполь¬ 
зование объектов по одной и той же схеме. В-четвертых, поскольку все объекты 
открываются и закрываются через менеджер объектов, несложно отследить, ка¬ 
кие объекты все еще используются, а какие можно безопасно удалить. В-пятых, 
эта однородная модель для управления объектов позволяет легко регулировать 
квоты ресурсов. 

Ключом к пониманию объектов является тот факт, что исполняемый объект 
представляет собой просто набор последовательных слов в памяти (то есть в вир¬ 
туальном адресном пространстве ядра). Объект представляет собой структуру дан¬ 
ных в памяти, не больше и не меньше. Файл на диске не является объектом, хотя 
для файла при его открытии создается объект (то есть структура данных в вирту¬ 
альном адресном пространстве ядра). Из того факта, что объекты представляют 
собой всего лишь структуры данных в виртуальном адресном пространстве ядра, 
следует, что при перезагрузке (или сбое) системы все объекты теряются. Дей¬ 
ствительно, когда операционная система загружается, нет никаких объектов (кро¬ 
ме бездействующих системных процессов, чьи объекты жестко прошиты в файле 
піозкті.ехе). Все остальные объекты создаются на ходу при загрузке системы и во 
время работы различных программ инициализации, а позднее пользовательских 
программ. 

Структура объектов показана на рис. 11.4. Каждый объект содержит заголовок 
с определенной информацией, общей для всех объектов всех типов. Поля заголов¬ 
ка включают имя объекта, каталог, в котором объект живет в пространстве объек¬ 
тов, информацию защиты (при открытии объекта выполняется определенная про¬ 
верка), а также список процессов, у которых есть открытые дескрипторы к данному 
объекту (если установлен определенный флаг отладки). 




864 


Глава 11. Рассмотрение конкретных случаев: ѴѴІпсіоѵѵв 2000 


Каждый заголовок объекта также содержит поле цены квоты, представляющей 
собой плату, взимаемую с процесса за открытие объекта. Если файловый объект 
стоит один пункт, а процесс принадлежит к заданию, у которого есть 10 пунктов 
квоты, то суммарно все процессы этого задания могут открыть не более 10 фай¬ 
лов. Таким образом, для объектов каждого типа могут реализовываться ограниче¬ 
ния на ресурсы. 


Заголовок 

объекта 


Данные / 
объекта \ 


Имя объекта 


Каталог, в котором живет объект 

Информация о защите 
(кто может использовать объект) 

Цена квоты 

(стоимость использования объекта) 


Имя типа 

Список процессов с манипуляторами 

Типы доступа 

Счетчик ссылок 

Права доступа 

Стоимость квоты 

Указатель на объект типа 

Синхронизируемый? 

Выгружаемый 

Данные, специфические для объекта 

Метод Орел 

Метод СІозе 

Метод Оеіеі 

Метод Сіиегу пате 
Метод Рагзе 

Метод Зесигііу 




Рис. 11.4. Структура объекта 

Объекты занимают важный ресурс — участки виртуального адресного про¬ 
странства ядра — поэтому, когда объект более не нужен, он должен быть удален, 
а его адресное пространство возвращено системе. Для этого в заголовке каждого 
объекта содержится счетчик ссылок на объект. Этот счетчик увеличивается на 
единицу каждый раз, когда объект открывается, и уменьшается на единицу при 
закрытии объекта. Когда значение счетчика уменьшается до 0, это означает, что 
никто более не пользуется этим объектом. Когда объект открывается или освобож¬ 
дается компонентом исполняющей системы, используется второй счетчик, даже 
если настоящий дескриптор при этом не создается. Когда оба счетчика умень¬ 
шаются до 0, это означает, что этот объект более не используется ни одним пользо¬ 
вателем и ни одним исполняющим процессом, то есть объект может быть удален, 
а его память освобождена. 

Менеджеру объектов бывает необходимо получать доступ к динамическим 
структурам данных (объектам), но он не единственная часть исполняющей систе¬ 
мы, которой это нужно. Другим частям исполняющей системы также бывает нуж¬ 
но динамически получать на время участки памяти. Для этого исполняющая сис¬ 
тема содержит два пула в адресном пространстве ядра: для объектов и для других 
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динамических структур данных. Эти пулы работают как «кучи», подобно проце¬ 
дурам языка С таііос и /гее для управления динамическими данными. Один пул 
является выгружаемым, а другой невыгружаемым (фиксированным в памяти). 
Объекты, обращения к которым часты, хранятся в невыгружаемом пуле; объекты, 
обращения к которым редки, например ключи реестра и некоторая информация, 
относящаяся к безопасности, хранятся в выгружаемом пуле. Когда памяти не хва¬ 
тает, этот пул может быть выгружен на диск и загружен обратно по страничному 
прерыванию. В действительности значительная часть программ и структур дан¬ 
ных операционной системы также является выгружаемой, что позволяет снизить 
потребление памяти. Объекты, которые могут понадобиться, когда система выпол¬ 
няет критический участок программы (и когда подкачка не разрешается), должны 
храниться в невыгружаемом пуле. Когда требуется небольшое количество памяти, 
страница может быть получена из любого пула, а затем разбита на мелкие участки 
размером от 8 байт. 

Объекты подразделяются на типы. Это означает, что у каждого объекта есть 
свойства, общие для всех объектов этого типа. Тип объекта определяется указате¬ 
лем на объект типа, как показано на рис. 11.4. Информация о типе объекта включает 
такие пункты, как название типа, данные о том, может ли поток ждать изменения 
состояния этого объекта (да для мьютексов, нет для открытых файлов), и должен 
ли объект этого типа храниться в выгружаемом или невыгружаемом пуле. Каждый 
объект указывает на свой объект типа. 

Наконец, самая важная часть объекта — это указатели на программы для опре¬ 
деленных стандартных операций, таких как ореп, сіозе и сіеіеѣе. Когда вызывается 
одна из этих операций, используется указатель на типовой объект, в котором выби¬ 
рается и выполняется соответствующая процедура. Такой механизм предоставля¬ 
ет системе возможность инициализировать новые объекты и освобождать память 
при их удалении. 

Компоненты исполняющей системы могут динамически создавать новые типы. 
Фиксированного списка типов объектов не существует, но некоторые наиболее 
употребительные типы приведены в табл. 11.6. Давайте кратко рассмотрим эти 
типы объектов. С процессом и потоком все ясно. Существует один объект для 
каждого процесса и для каждого потока. В объекте хранятся основные свойства, 
необходимые для управления этим процессом или потоком. Следующие три объек¬ 
та, семафор, мьютекс и событие, имеют отношение к синхронизации процессов. 
Семафоры и мьютексы работают так, как и ожидается, но с дополнительными функ¬ 
циями (например, максимальными значениями и тайм-аутами). События могут 
быть в одном из двух состояний: сигнализирующем и несигнализирующем. Если 
поток ждет события, находящегося в сигнализирующем состоянии, он немедлен¬ 
но получает управление. Если же ожидаемое потоком событие находится в несиг¬ 
нализирующем состоянии, тогда поток блокируется до тех пор, пока какой-либо 
другой поток не переведет это событие в сигнализирующее состояние (проще гово¬ 
ря, пока это событие не произойдет). Событие может также быть настроено таким 
образом, что после получения сигнала ожидающим его процессом это событие 
автоматически перейдет в несигнализирующее состояние. В противном случае 
событие останется в сигнализирующем состоянии. 




866 Глава 11. Рассмотрение конкретных случаев: ѴѴІпсіоѵѵз 2000 


Таблица 11.6. Некоторые общие типы объектов исполняющей системы, 
управляемых менеджером объектов 

Тип 

Описание 

Процесс 

Процесс пользователя 

Поток 

Поток внутри процесса 

Семафор 

Семафор со счетчиком, используемый для синхронизации процессов 

Мьютекс 

Двоичный семафор, используемый для входа в критическую область 

Событие 

Объект синхронизации с перманентным состоянием 
(сигнализирующий/нет) 

Порт 

Механизм для передачи сообщений между процессами 

Таймер 

Объект, позволяющий потоку спать в течение фиксированного 
интервала времени 

Очередь 

Объект, используемый для уведомления о завершении асинхронного 
ввода-вывода 

Открытый файл 

Объект, ассоциированный с открытым файлом 

Маркер доступа 

Описатель защиты для некоторого объекта 

Профиль 

Структура данных, используемая для анализа использования 
центрального процессора 

Секция 

Структура, используемая для отображения файлов на виртуальное 
адресное пространство 

Ключ 

Ключ реестра 

Каталог объектов 

Каталог для группирования объектов в менеджере объектов 

Символьная ссылка 

Указатель на другой объект по имени 

Устройство 

Объект устройства ввода-вывода 

Драйвер устройства 

У каждого загруженного драйвера устройства есть свой объект 


Объекты порт, таймер и очередь также имеют отношение к связи и синхрони¬ 
зации. Порты представляют собой каналы между процессами, использующиеся 
для обмена сообщениями. Таймеры предоставляют способ блокировать процесс 
или поток на определенный срок. Очереди применяются для уведомления пото¬ 
ков о том, что начатая ранее асинхронная операция ввода-вывода завершена. 

Объекты открытых файлов создаются при открытии файла. У неоткрытых фай¬ 
лов нет объектов, управляемых менеджером объектов. Маркеры доступа представ¬ 
ляют собой объекты безопасности. Они идентифицируют пользователя и сообща¬ 
ют, какие привилегии имеет этот пользователь. Профили представляют собой 
структуры, используемые для хранения периодически фиксируемых значений 
счетчика команд работающего потока, которые позволяют определить, на что дан¬ 
ная программа тратит свое время. 

Секции являются объектами, используемыми системой памяти для управле¬ 
ния отображаемыми на память файлами. Они хранят сведения о том, какой файл 
(или часть файла) на какие адреса памяти отображается. Ключи представляют со¬ 
бой ключи реестра и применяются для установки связи между именем и значени¬ 
ем. Каталоги объектов являются полностью локальными по отношению к менед¬ 
жеру объектов. Они предоставляют способ объединять связанные объекты тем же 
способом, каким обычные каталоги объединяют файлы в файловой системе. 
Символьные ссылки также подобны своим двойникам в файловой системе: они 
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позволяют имени в одной части пространства имен объектов ссылаться на объект 
в другой части этого пространства имен. У каждого известного системе устрой¬ 
ства есть объект устройства, содержащий информацию о нем и использующийся 
для ссылки на устройство в системе. Наконец, у каждого загруженного драйвера 
устройства есть объект в пространстве объектов. 

Пользователи могут создавать новые объекты или открывать уже существующие 
объекты при помощи вызовов ^іп32, таких как СгеаѣеЗетарІюге и ОрепЗетарІюге. 
Эти вызовы являются библиотечными процедурами, которые в конечном итоге об¬ 
ращаются к настоящим системным вызовам. При успешном выполнении первый вы¬ 
зов создает, а второй открывает объект, создавая в результате 64-разрядную запись 
в таблице дескрипторов, хранящуюся в приватной таблице дескрипторов процес¬ 
са в памяти ядра. Пользователю для последующей работы возвращается 32-раз- 
рядный индекс, указывающий положение дескриптора в таблице. 

64-разрядный элемент таблицы дескрипторов в ядре содержит два 32-разряд- 
ных слова. Одно слово содержит 29-разрядный указатель на заголовок объекта. 
Младшие три разряда используются как флаги (например, указывающие, насле¬ 
дуется ли дескриптор дочерним процессом). Когда указатель используется, эти 
разряды маскируются. Второе слово содержит 32-разрядную маску прав доступа. 
Она нужна, потому что проверка разрешений выполняется только в то время, когда 
объект создается или открывается. Если у процесса есть только разрешение для 
чтения объекта, тогда все остальные биты маски будут нулями, что дает системе 
возможность отвергать любую операцию, кроме операции чтения. 

На рис. 11.5 показаны таблицы дескрипторов для двух процессов и их взаимо¬ 
отношения с некоторыми объектами. В данном примере у процесса Л есть доступ 
к потокам 1 и 2, а также доступ к мьютексам 1 и 2. У процесса В есть доступ к по¬ 
току 3 и к мьютексам 2 и 3. В соответствующих элементах таблицы дескрипторов 
хранятся права доступа к каждому из этих объектов. Так, у процесса Л есть права 
блокировать и разблокировать его мьютексы, но нет права уничтожить их. Обра¬ 
тите внимание, что мьютекс 2 используется совместно двумя процессами, обеспе¬ 
чивая синхронизацию их потоков. Остальные мьютексы не являются совместно 
используемыми. Это может означать, что потоки процесса Л используют для своей 
внутренней синхронизации мьютекс 1, а потоки процесса В для своей внутренней 
синхронизации пользуются мьютексом 3. 

Пространство имен объектов 

По мере того как во время выполнения программы создаются и удаляются объек¬ 
ты, менеджеру объектов необходимо следить за ними. Для выполнения этой работы 
он поддерживает пространство имен, в котором располагаются все объекты систе¬ 
мы. Пространство имен может использоваться процессом, чтобы найти и открыть 
дескриптор объекта другого процесса при условии, что для этого у него есть необхо¬ 
димые разрешения. Пространство имен объектов является одним из трех пространств 
имен, поддерживаемых в \Ѵіпс1о\ѵ8 2000. Остальные два представляют собой про¬ 
странство имен файловой системы и пространство имен реестра. Все три являются 
иерархическими пространствами имен со множеством уровней каталогов для орга¬ 
низации элементов. Объекты каталогов, упомянутые в табл. 11.6, предоставляют 
средства реализации этого иерархического пространства имен для объектов. 
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Таблица 
манипуляторов 
для процесса А 


Поток 


Поток 


Поток 


Поток 

1 


2 


3 


4 


Таблица 
манипуляторов 
для процесса В 



Рис. 11.5. Взаимоотношения между таблицами дескрипторов, объектами и типовыми объектами 

Поскольку объекты исполняющей системы являются временными (то есть ис¬ 
чезают при выключении компьютера, в отличие от файловой системы и элемен¬ 
тов реестра), в начале загрузки системы в памяти нет объектов и пространство 
имен объектов пусто. Во время загрузки различные части исполняющей системы 
создают каталоги и заполняют их объектами. Например, когда менеджер р1щ*-апс[- 
ріау обнаруживает новые устройства, он создает по объекту для каждого устройства 
и помещает эти объекты в пространство имен. Когда система полностью загружена, 
все устройства ввода-вывода, дисковые разделы и другие интересные открытия 
системы оказываются в пространстве имен объектов. 

Не все объекты создаются по методу Колумба — просто отправиться посмотреть, 
что удастся найти. Некоторые компоненты исполняющей системы смотрят в реестр, 
чтобы определить, что им делать. Важнейший пример — драйверы устройств. 
При загрузке система смотрит в реестр, чтобы узнать, какие драйверы ей нужны. 
При загрузке каждого драйвера создается объект, а его имя добавляется в про¬ 
странство имен объектов. В системе обращение к драйверу осуществляется по ука¬ 
зателю на его объект. 

Хотя пространство имен объектов является центральным для всего функцио¬ 
нирования системы, почти никому не известно о его существовании, потому что 
без специальных средств просмотра оно невидимо для пользователей. Одним из 
таких инструментов просмотра является программа тіпоЬі, которую можно бес¬ 
платно получить на сайте ѵѵѵѵѵѵ.зузіпіегпаіз.сот. При запуске эта программа отобра¬ 
жает пространство имен объектов, как правило, содержащее каталоги объектов, 
некоторые из них перечислены в табл. 11.7. 
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Таблица 11 .7. Некоторые типичные каталоги пространства имен объектов 


Каталог Содержание 


?? 

Оеѵісе 

Ргіѵег 

ОЬІесІТурез 

ѴѴіпсІоѵѵз 

ВазеЫатесЮЬі'з 

Агспате 

N15 

РіІеЗузІет 

Зесигііу 

КпоѵѵпОІ-1-з 


Начальное место для поиска устройств М5-005, например, С: 

Все обнаруженные устройства ввода-вывода 

Объекты, соответствующие каждому загруженному драйверу устройства 
Объекты типов, показанные на рис. 11.5 
Объекты для отправки сообщений всем окнам 

Объекты, создаваемые пользователем, такие как семафоры, мьютексы и т. д. 
Имена разделов, обнаруженные загрузчиком 
Объекты языковой поддержки 

Объекты драйверов файловой системы и объекты распознавателя файловой 
системы 

Объекты системы безопасности 

Совместно используемые библиотеки, находящиеся в открытом состоянии 


Может показаться несколько странным, что каталог, названный \??, содержит 
все имена устройств стиля М5-Э05, такие как А: для гибкого диска и С: для пер¬ 
вого жесткого диска. Эти имена в действительности представляют собой символь¬ 
ные ссылки на каталог \Оеѵісе, в котором располагаются объекты устройств. Имя 
\?? было выбрано, чтобы оно оказывалось первым в алфавитном порядке для уско¬ 
рения поиска всех путей, начинающихся с буквы привода. Содержимое остальных 
каталогов должно говорить само за себя. 

Подсистемы окружения 

Возвращаясь к рис. 11.2, мы видим, что операционная система ІѴтсІохѵв 2000 
состоит из компонентов, работающих в режиме ядра, и компонентов, работающих 
в режиме пользователя. Мы закончили наше изучение компонентов, работающих 
в режиме ядра, теперь пора перейти к обсуждению компонентов, работающих в ре¬ 
жиме пользователя. Существует три типа таких компонентов: динамические биб¬ 
лиотеки ОЬЬ, подсистемы окружения и служебные процессы. Эти компоненты 
работают вместе, предоставляя каждому пользовательскому процессу интерфейс, 
отличный от интерфейса системных вызовов ІѴтсІохѵз 2000. 

Операционной системой ІѴтсІохѵв 2000 поддерживаются три различных доку¬ 
ментированных интерфейса прикладного программирования АРІ: 1ѴІП32, Р05ІХ 
и 05/2. У каждого из этих интерфейсов есть список библиотечных вызовов, ко¬ 
торые могут использовать программисты. Работа библиотек ЭЬЬ (Оупашіс Ьіпк 
ЬіЬгагу — динамически подключаемая библиотека) и подсистем окружения за¬ 
ключается в том, чтобы реализовать функциональные возможности опубликован¬ 
ного интерфейса, тем самым скрывая истинный интерфейс системных вызовов 
от прикладных программ. В частности, интерфейс ^іп32 является официальным 
интерфейсом для операционных систем ІУтсІохѵв 2000, ІУіпсІохѵв >ГГ, ІУіпсІохѵв 95/ 
98/Ме и, в некоторой степени, для ІУіпсІохѵв СЕ. При использовании библиотеки 
ОЬЬ и подсистемы окружения 1Ут32 программа может быть написана в соот¬ 
ветствии со спецификацией ЛѴіп32, в результате чего она сможет без каких-либо 




870 


Глава 11. Рассмотрение конкретных случаев: ѴѴіпсіоѵѵв 2000 


изменений работать на всех этих версиях \Ѵіп<іо\ѵ5, несмотря на то, что сами сис¬ 
темные вызовы в различных системах различны. 

Рассмотрим способ реализации этих интерфейсов на примере \Ѵіп32. Програм¬ 
ма, пользующаяся интерфейсом ЛѴіп32, как правило, состоит из большого коли¬ 
чества обращений к функциям Шт32 АРІ, например СгеаІеМіпсіои, ОгамМепиВаг 
и ОрепЗетарІюге. Существуют тысячи подобных вызовов, и большинство программ 
использует значительное их количество. Один из возможных способов реализа¬ 
ции заключается в статическом связывании каждой программы, использующей 
интерфейс Шт32, со всеми библиотечными процедурами, которыми она пользу¬ 
ется. При таком подходе каждая двоичная программа будет содержать копию всех 
используемых ею процедур в своем исполняемом двоичном файле. 

Недостаток такого подхода заключается в том, что при этом расходуется много 
памяти, если пользователь одновременно откроет несколько программ, использу¬ 
ющих одни и те же библиотечные процедуры. Например, программы Ѵ/огН, Ехсеі и 
Ротегроіпі используют абсолютно одинаковые процедуры для открытия диалого¬ 
вых окон, рисования окон, отображения меню, работы с буфером обмена и т. д. 
Поэтому, если одновременно открыть все эти программы, при такой реализации 
программ в памяти будут находиться три (идентичные) копии каждой библиотеч¬ 
ной процедуры. 

Чтобы избежать подобной проблемы, все версии Штс1о\У5 поддерживают ди¬ 
намические библиотеки, называемые ОЬЬ (Бупашіс-Ыпк ЬіЬгагу — динамически 
подсоединяемая библиотека). Каждая динамическая библиотека содержит набор 
тесно связанных библиотечных процедур и все их структуры данных в одном фай¬ 
ле, как правило (но не всегда), с расширением АН. Когда приложение компонуется, 
компоновщик видит, что некоторые библиотечные процедуры принадлежат к ди¬ 
намическим библиотекам, и записывает эту информацию в заголовок исполняе¬ 
мого файла. Обращения к процедурам динамических библиотек производятся не 
напрямую, а при помощи вектора передачи в адресном пространстве вызывающе¬ 
го процесса. Изначально этот вектор заполнен нулями, так как адреса вызываемых 
процедур еще неизвестны. 

При запуске прикладного процесса все требуемые динамические библиотеки 
обнаруживаются (на диске или в памяти) и отображаются на виртуальное адрес¬ 
ное пространство процесса. Затем вектор передачи заполняется верными адреса¬ 
ми, что позволяет вызывать библиотечные процедуры через этот вектор с незна¬ 
чительной потерей производительности. Выигрыш такой схемы заключается в том, 
что при запуске нескольких приложений, использующих одну и ту же динамичес¬ 
кую библиотеку, в физической памяти требуется только одна копия текста БЬЬ 
(но каждый процесс получает свою собственную копию приватных статических 
данных в БЫ.). В операционной системе \Ѵіпс1о\ѵз 2000 динамические библиоте¬ 
ки используются очень активно для всех аспектов системы. 

Теперь мы достаточно подготовились к тому, чтобы понять, как реализован 
интерфейс Шт32, а также другие интерфейсы. Каждый пользовательский процесс, 
как правило, связан с несколькими динамическими библиотеками, совместно реа¬ 
лизующими интерфейс Шіп32. Чтобы обратиться к вызову АРІ, вызывается одна 
из процедур в БЬЬ (шаг 1 на рис. 11.6). Дальнейшие действия зависят от вызова 
Шт32 АРІ. Различные вызовы реализованы по-разному. 
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В некоторых случаях динамические библиотеки обращаются к другой динами¬ 
ческой библиотеке ( пЫИЯИ ) которая, в свою очередь, обращается к ядру операци¬ 
онной системы. Этот путь показан на рисунке как шаги 2а и За. Динамическая биб¬ 
лиотека может также выполнить всю работу самостоятельно, совсем не обращаясь 
к системным вызовам. Для других вызовов \Ѵіп32 АРІ выбирается другой маршрут, 
а именно: сначала процессу подсистемы \Ѵіп32 (с$г$$.ехё) посылается сообщение, 
выполняющее некоторую работу, и обращающееся к системному вызову (шаги 26, 
36 и 46). При этом в некоторых случаях подсистема также выполняет всю работу 
в пространстве пользователя и немедленно возвращает управление. Передача 
сообщения между прикладным процессом и процессом подсистемы \Ѵіп32 была 
старательно оптимизирована по времени, для чего был использован специальный 
механизм вызова локальной процедуры, реализованный в исполняющей системе 
и показанный как ЬРС на рис. 11.2. 

В первой версии \Ѵіпс1о\Ѵ5 N7 практически все вызовы \Ѵіп32 АРІ выбира¬ 
ли маршрут 26, 36, 46, так как большая часть операционной системы (например, 
графика) была помещена в пространство пользователя. Однако, начиная с версии 
N7 4.0, для увеличения производительности большая часть кода была перенесена 
в ядро (в драйвер \Ѵіп32/СОІ на рис. 11.2). В АѴіпсіоѵѵз 2000 только небольшое 
количество вызовов \Ѵіп32 АРІ, например вызовы для создания процесса или по¬ 
тока, идут по длинному пути. Остальные вызовы выполняются напрямую, минуя 
подсистему окружения \Ѵіп32. 

Следует также сказать, что на рис. 11.6 показаны три наиболее важные ЭЬЬ, 
но они не являются единственными динамическими библиотеками в системе. 
В каталоге \тппІ\5у$І:ет32 есть более 800 отдельных файлов ГЗЬЬ общим объемом 
в 130 Мбайт. Количество содержащихся в них вызовов АРІ превышает 13 000. 
(В конце концов, 29 млн строк исходного текста должны были где-то храниться 
после компиляции.) Некоторые наиболее важные файлы динамических библио¬ 
тек перечислены в табл. 11.8. Для каждого файла приведено количество экспорти¬ 
руемых функций (то есть видимых за пределами файла), но этот параметр меня- 
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ется со временем (увеличивается). Число экспортируемых функций в первом 
открытом выпуске пЫИ.сШ для \Ѵіпс]о\ѵз 2000 было равно 1179. Они представляют 
собой настоящие системные вызовы. 1209 вызовов, экспортируемых из файла 
піозкті.ехе, являются функциями, доступными для драйверов устройств и других 
программ, связанных с ядром. Вызовы в файле тп32к.зуз формально не экспорти¬ 
руются, так как файл тіп32к.зуз не вызывается напрямую. Список экспортируе¬ 
мых функций в любом файле .ехе или ЯП можно просмотреть программой сІерепсЬ, 
входящей в пакет Ріаііогш 50К (5оЙ\ѵаге Оеѵеіортепі КіС). 


Таблица 11.8. Некоторые ключевые файлы ѴѴіпсІоѵѵз 2000, их режим работы, 
количество экспортируемых функций и основное содержание 
каждого файла 


Файл 

Режим 

Количество 

функций 

Содержание 

ЬаІ.бІІ 

Ядра 

95 

Низкоуровневое управление аппаратурой, 
например портами ввода-вывода 

піозкгпі.ехе 

Ядра 

1209 

Операционная система ѴѴІпсіоѵѵз 2000 
(ядро + исполняющая система) 

\д/іп32к.зуз 

Ядра 

“ 

Множество системных вызовов, включая 
большую часть графики 

ПЙІІ.СІІІ 

Пользователя 

1179 

Диспетчер перехода из режима пользователя 
в режим ядра 

сзгзз.ехе 

Пользователя 

0 

Процесс подсистемы окружения ѴѴіп32 

кегпеІ32.сіІІ 

Пользователя 

823 

Большая часть системных вызовов ядра 
(неграфических) 

дсіі32.сіІІ 

Пользователя 

543 

Шрифт, текст, цвет, кисть, перо, растровые 
изображения, палитра, рисование и т. д. 

изег32.сІІІ 

Пользователя 

695 

Окна, значки, меню, курсоры, диалоговые 
окна, буфер обмена и т. д. 

ас)ѵарі32.сіІІ 

Пользователя 

557 

Защита, шифрование, реестр 


Хотя интерфейс процессов \Ѵіп32 является наиболее важным, в операционной 
системе \Ѵіпс1о\Ѵ5 2000 существует еще два интерфейса: РОЗІХ и 05/2. Среда 
Р05ІХ предоставляет минимальную поддержку для приложений ІШІХ. Она под¬ 
держивает практически только функции, описанные в стандарте Р1003.1. Этим 
интерфейсом, например, не поддерживаются потоки, работа с окнами или сетью. 
Перенос любой реальной программы из системы ІШІХ в \Ѵіпс1о\Ѵ5 2000 при помо¬ 
щи этой подсистемы практически невозможен. Этот интерфейс был включен толь¬ 
ко потому, что некоторые министерства правительства США требовали, чтобы 
операционные системы для правительственных компьютеров были совместимы со 
стандартом Р 1003.1. Эта подсистема не является самодостаточной и пользуется 
вызовами подсистемы \Ѵіп32 для большей части своей работы, но не предостав¬ 
ляя пользовательским программам полного интерфейса \Ѵіп32 (если бы это было 
сделано корпорацией МісгозоФ, то подсистемой можно было бы пользоваться, при¬ 
чем для этого не потребовалось бы никаких специальных усилий). 

Чтобы облегчить пользователям ІШІХ переход на \Ѵіпс1о\ѵ5 2000, корпорация 
МісгозоЙ также разработала программный продукт ІпСегіх, предоставляющий более 
высокую степень совместимости с системой ІШІХ, чем подсистема РОЗІХ. 
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Функциональность подсистемы 08/2 ограничена практически в той же степе¬ 
ни, что и функциональность подсистемы Р05ІХ. Подсистема 05/2 также не под¬ 
держивает графические приложения. На практике она тоже полностью бесполезна. 
Таким образом, оригинальная идея наличия интерфейсов нескольких операци¬ 
онных систем, реализованных различными процессами в пространстве пользова¬ 
теля, окончилась ничем. Осталась лишь полная реализация интерфейса \Ѵіп32 
в режиме ядра. 


Процессы и потоки в ѴѴіпсІоѵѵз 2000 

В операционной системе \Ѵіпс1о\Ѵ5 2000 есть множество концепций для управле¬ 
ния центральным процессором и объединения ресурсов. В следующих разделах мы 
их обсудим, рассмотрим некоторые соответствующие вызовы \Ѵіп32 АРІ, а также 
покажем, как эти концепции реализованы. 

Основные понятия 

В операционной системе \Ѵіпс1о\ѵ5 2000 поддерживаются традиционные процес¬ 
сы, способные общаться и синхронизироваться друг с другом так же, как это дела¬ 
ют процессы в ІЖІХ. Каждый процесс содержит по крайней мере один поток, со¬ 
держащий, в свою очередь, как минимум одно волокно (облегченный поток). Более 
того, для управления определенными ресурсами процессы могут объединяться 
в задания. Все вместе — задания, процессы, потоки и волокна — образует общий 
набор инструментов для управления ресурсами и реализации параллелизма как 
на однопроцессорных, так и на многопроцессорных машинах. Краткое описание 
этих четырех понятий приведено в табл. 11.9. 

Таблица 11.9. Основные понятия, используемые для управления 
центральным процессором и ресурсами 

Назввние Описание 

Задание Набор процессов с общими квотами и лимитами 
Процесс Контейнер для ресурсов 

Поток Сущность, планируемая ядром 

Волокно Облегченный поток, управляемый полностью в пространстве пользователя 


Рассмотрим по очереди эти понятия, начиная с самого крупного и заканчивая 
самым маленьким. Задание в \Ѵіпсіо\ѵ5 2000 представляет собой набор, состоящий 
из одного или нескольких процессов, управляемых как единое целое. В частности, 
с каждым заданием ассоциированы квоты и лимиты ресурсов, хранящиеся в соот¬ 
ветствующем объекте задания. Квоты включают такие пункты, как максимальное 
количество процессов (не позволяющее процессам задания создавать бесконтроль¬ 
ное количество дочерних процессов), суммарное время центрального процессора, 
доступное для каждого процесса в отдельности и для всех процессов вместе, а также 
максимальное количество используемой памяти для процесса и для всего задания. 
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Задания также могут ограничивать свои процессы в вопросах безопасности, на¬ 
пример, запрещать им получать права администратора (суперпользователя) даже 
при наличии правильного пароля. 

Процессы являются более интересными, чем задания, а также более важны¬ 
ми. Как и в системе ІЖІХ, процессы представляют собой контейнеры для ресур¬ 
сов. У каждого процесса есть 4-гигабайтное адресное пространство, в котором 
пользователь занимает нижние 2 Гбайт (в версиях \Ѵіпс1о\ѵ5 2000 Абѵапсесі Зегѵег 
и Оаіасепіег Зегѵег этот размер может быть по желанию увеличен до 3 Гбайт), 
а операционная система занимает остальную его часть. Таким образом, операци¬ 
онная система присутствует в адресном пространстве каждого процесса, хотя она 
и защищена от изменений с помощью аппаратного блока управления памятью 
ММ II. У процесса есть идентификатор процесса, один или несколько потоков, 
список дескрипторов (управляемых в режиме ядра) и маркер доступа, хранящий 
информацию защиты. Процессы создаются с помощью вызова \Ѵіп32, который 
принимает на входе имя исполняемого файла, определяющего начальное содер¬ 
жимое адресного пространства, и создает первый поток. 

Каждый процесс начинается с одного потока, но новые потоки могут создавать¬ 
ся динамически. Потоки формируют основу планирования центрального процес¬ 
сора, так как операционная система всегда для запуска выбирает поток, а не про¬ 
цесс. Соответственно, у каждого потока есть состояние (готовый, работающий, 
блокированный и т. д.), тогда как у процессов состояний нет. Потоки могут дина¬ 
мически создаваться вызовом \Ѵіп32, которому в адресном пространстве процесса 
задается адрес начала исполнения. У каждого потока есть идентификатор потока, 
выбираемый из того же пространства, что и идентификаторы процессов, поэтому 
один и тот же идентификатор никогда не будет использован одновременно для 
процесса и для потока. Идентификаторы процессов и потоков кратны четырем, 
поэтому они могут использоваться в роли байтовых индексов в таблицах ядра, как 
и другие объекты. 

Как правило, поток работает в пользовательском режиме, но когда он обраща¬ 
ется к системному вызову, то переключается в режим ядра, после чего продолжает 
выполнять тот же поток, с теми же свойствами и ограничениями, которые были 
у него в режиме пользователя. У каждого потока есть два стека, один используется 
в режиме ядра, а другой в режиме пользователя. Помимо состояния, идентифика¬ 
тора и двух стеков, у каждого потока есть контекст (в котором сохраняются его 
регистры, когда он не работает), приватная область для локальных переменных, 
а также может быть свой собственный маркер доступа. Если у потока есть свой мар¬ 
кер доступа, то он перекрывает маркер доступа процесса, чтобы клиентские потоки 
могли передать свои права доступа серверным потокам, выполняющим работу для 
них. Когда поток завершает свою работу, он может прекратить свое существование. 
Когда прекращает существование последний активный поток, процесс завершается. 

Важно понимать, что потоки представляют собой концепцию планирования, 
а не концепцию владения ресурсами. Любой поток может получить доступ ко всем 
объектам его процесса. Все, что ему для этого нужно сделать, — это заполучить дес¬ 
криптор и обратиться к соответствующему вызову \Ѵіп32. Для потока нет ника¬ 
ких ограничений доступа к объекту, связанных с тем, что этот объект создан или 
открыт другим потоком. Система даже не следит за тем, какой объект каким пото- 
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ком создан. Как только дескриптор объекта помещен в таблицу дескрипторов про¬ 
цесса, любой поток процесса может его использовать. 

Помимо нормальных потоков, работающих в процессах пользователя, в опера¬ 
ционной системе \ѴіпсІо\ѵ5 2000 есть множество процессов-демонов, не связанных 
ни с каким пользовательским процессом (они ассоциированы со специальной си¬ 
стемой или простаивающими процессами). Некоторые демоны выполняют адми¬ 
нистративные задачи, как, например, запись «грязных» страниц на диск, тогда 
как другие формируют пул, и ими могут пользоваться компоненты исполняющей 
системы или драйверы, которым нужно выполнить какие-либо асинхронные за¬ 
дачи в фоновом режиме. Некоторые из этих потоков будут рассмотрены позднее, 
когда мы дойдем до темы управления памятью. 

Переключение потоков в операционной системе \ѴіпсІо\ѵ5 2000 занимает до¬ 
вольно много времени, так как для этого необходимо переключение в режим ядра, 
а затем возврат в режим пользователя. Для предоставления сильно облегченного 
псевдопараллелизма в \Ѵіпс1о\ѵз 2000 используются волокна, подобные потокам, 
но планируемые в пространстве пользователя создавшей их программой (или ее 
системой поддержки исполнения). У каждого потока может быть несколько воло¬ 
кон, так же как у процесса может быть несколько потоков, с той разницей, что когда 
волокно логически блокируется, оно помещается в очередь блокированных волокон, 
после чего для работы выбирается другое волокно в контексте того же потока. 

Операционная система не знает о смене волокон, так как все тот же поток 
продолжает работу. Так как операционная система ничего не знает о волокнах, 
то с ними, в отличие от заданий, процессов и потоков, не связаны объекты испол¬ 
няющей системы. Для управления волокнами нет и настоящих системных вызо¬ 
вов. Однако для этого есть вызовы \Ѵіп32 АРІ. Они относятся к тем вызовам 
\Ѵіп32 АРІ, которые не обращаются к системным вызовам, о чем уже рассказыва¬ 
лось при обсуждении рис. 11.6. Взаимосвязь между заданиями, процессами и по¬ 
токами показана на рис. 11.7. (Несколько волокон могут объединяться в одном 
потоке, что не показано на рисунке.) 



Рис. 11.7. Взаимосвязь между заданиями, процессами и потоками 
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Хотя мы не будем подробно обсуждать эту тему, следует сказать, что операци¬ 
онная система \Ѵтс1о\ѵ5 2000 может работать на симметричных многопроцессор¬ 
ных системах. Это означает, что код операционной системы должен быть полнос¬ 
тью реентерабельным, то есть каждая процедура должна быть написана таким 
образом, чтобы два или более центральных процессора могли поменять свои пере¬ 
менные без особых проблем. Во многих случаях это означает, что программные 
секции должны быть защищены при помощи спин-блокировки или мьютексов, 
удерживающих дополнительные центральные процессоры в режиме ожидания, 
пока первый центральный процессор не выполнит свою работу (при помощи по¬ 
следовательного доступа к критическим областям). Количество поддерживаемых 
системой процессоров управляется лицензионными ограничениями. Эти значения 
приведены в табл. 11.2. Нет никаких технических причин, по которым система 
\Ѵіпс1о\Ѵ5 Ргоіеззіопаі не может работать на мультипроцессоре с 32 узлами — в кон¬ 
це концов, у нее тот же самый двоичный код, что и у версии Баіасепіег Зегѵег. 

Верхний предел в 32 центральных процессора является жестким пределом, так 
как во многих местах операционной системы для учета использования централь¬ 
ных процессоров используются битовые массивы размером в 32-разрядное машин¬ 
ное слово. Например, один однословный битовый массив используется для того, 
чтобы следить, какой из центральных процессоров свободен в данный момент, 
а другой массив используется в каждом процессе для перечисления центральных 
процессоров, на которых этому процессу разрешено работать. 64-разрядная версия 
\Ѵіпс1о\ѵ5 2000 должна будет без особых усилий поддерживать до 64 центральных 
процессоров. Для превышения этого ограничения потребуется существенная пере¬ 
делка программы (с использованием по нескольку слов для битовых массивов). 

Вызовы АРІ для управления заданиями, 
процессами, потоками и волокнами 

Новые процессы создаются при помощи функции \Ѵіп32 АРІ СгеаІеРгосезз. У этой 
функции 10 параметров, каждый из которых может задаваться в различных вари¬ 
антах. Такая схема, очевидно, значительно сложнее схемы, применяемой в ІШІХ, 
в которой системный вызов Гогк вообще не имеет параметров, а у системного вы¬ 
зова ехес их всего три: указатели на имя исполняемого файла, массив параметров 
командной (проанализированной) строки и строки окружения. Если не вдаваться 
в подробности, то у вызова СгеаІеРгосезз следующие 10 параметров: 

1. Указатель на имя исполняемого файла. 

2. Сама командная строка (непроанализированная). 

3. Указатель на описатель защиты процесса. 

4. Указатель на описатель защиты для начального потока. 

5. Бит, управляющий наследованием дескрипторов. 

6. Разнообразные флаги (например, режим ошибки, приоритет, отладка, кон¬ 
соли). 

7. Указатель на строки окружения. 
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8. Указатель на имя текущего рабочего каталога нового процесса. 

9. Указатель на структуру, описывающую начальное окно на экране. 

10. Указатель на структуру, возвращающую вызывающему процессу 18 значений. 

В операционной системе \Ѵіпсіоѵу5 2000 не поддерживается какой-либо иерар¬ 
хии процессов, например «родительский-дочерний». Все созданные процессы рав¬ 
ны (не существует процессов, более равных, чем другие). Однако, поскольку один 
из 18 параметров, возвращаемых вызывающему процессу, представляет собой 
дескриптор нового процесса (что предоставляет контроль над новым процессом), 
существует негласная иерархия, заключающаяся в том, кто чьим дескриптором 
владеет. Хотя эти дескрипторы не могут напрямую передаваться другим процес¬ 
сам, у процесса есть способ создать дубликат дескриптора. Дубликат дескриптора 
может быть передан другому процессу и использоваться им, поэтому неявная 
иерархия процессов может просуществовать недолго. 

Каждый процесс в \Ѵіпс1о\ѵ5 2000 создается с одним потоком, но процесс мо¬ 
жет позднее создать дополнительные потоки. Создание потока проще создания 
процесса — у вызова СгеаІеТИгеасІ всего шесть параметров вместо десяти: 

1. Описатель защиты (необязательный). 

2. Начальный размер стека. 

3. Адрес запуска. 

4. Параметр, задаваемый пользователем. 

5. Начальное состояние потока (готовый или блокированный). 

6. Идентификатор потока. 

Созданием потоков занимается ядро, поэтому оно имеет полное представление 
о потоках (потоки не реализуются полностью в пространстве пользователя, как это 
делается в некоторых других системах). 

Межпроцессное взаимодействие 

Для общения друг с другом потоки могут использовать широкий спектр возмож¬ 
ностей, включая каналы, именованные каналы, почтовые ящики, вызов удаленной 
процедуры и совместно используемые файлы. Каналы могут работать в одном из 
двух режимов, выбираемом при создании канала: байтовом и режиме сообщений. 
Байтовые каналы работают так же, как и в системе ІЖІХ. Каналы сообщений в чем- 
то похожи на байтовые каналы, но сохраняют границы между сообщениями, так 
что четыре записи по 128 байт будут читаться с другой стороны канала как четыре 
сообщения по 128 байт, а не как одно 512-байтовое сообщение, как это может слу¬ 
читься с байтовыми каналами. Также имеются именованные каналы, для которых 
существуют те же два режима. Именованные каналы, в отличие от обычных кана¬ 
лов, могут использоваться по сети. 

Почтовые ящики представляют собой особенность системы \Ѵіпсіоѵу5 2000, 
которой нет в ИШХ. В некоторых аспектах они подобны каналам, но не во всем. 
Во-первых, почтовые ящики являются однонаправленными, тогда как кана¬ 
лы могут работать в обоих направлениях. Они также могут использоваться по 
сети, но не предоставляют гарантированной доставки. Наконец, они позволяют 
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отправляющему процессу использовать широковещание для рассылки сообщения 
не одному, а сразу многим получателям. 

Сокеты подобны каналам с тем отличием, что они при нормальном использо¬ 
вании соединяют процессы на разных машинах. Например, один процесс пишет в 
сокет, а другой процесс на удаленной машине читает из него. Сокеты также могут 
использоваться для соединения процессов на одной машине, но поскольку их ис¬ 
пользование влечет за собой большие накладные расходы, чем использование ка¬ 
налов, то, как правило, они применяются в контексте сети. 

Вызов удаленной процедуры представляет собой тот способ, которым процесс А 
просит процесс В вызвать процедуру в адресном пространстве процесса В от име¬ 
ни процесса Л и вернуть результат процессу Л. Существуют различные ограниче¬ 
ния на параметры. Например, нет смысла передавать указатель другому процессу. 

Наконец, процессы могут совместно использовать память для одновременного 
отображения одного и того же файла. Все, что один процесс будет писать в этот 
файл, будет появляться в адресном пространстве других процессов. С помощью 
такого механизма можно легко реализовать общий буфер, применяемый в задаче 
производителя и потребителя. 

Помимо многочисленных механизмов межпроцессного взаимодействия, опера¬ 
ционная система \ѴтсІоѵг5 2000 также предоставляет множество механизмов син¬ 
хронизации, включая семафоры, мьютексы, критические регионы и события. Все 
эти механизмы работают с потоками, а не процессами, так что когда поток блоки¬ 
руется на семафоре, другие потоки этого процесса (если такие есть) не затрагива¬ 
ются и могут продолжать работу. 

Семафор создается при помощи АРІ-функции СгеаѣеБетарИоге, которая может 
задать для него начальное значение, а также установить максимальное значение. 
Семафоры представляют собой объекты в ядре и, таким образом, обладают деск¬ 
рипторами или дескрипторами защиты. Копия дескриптора может быть получена 
с помощью функции Оирі і саѣеНапсЛ е и передана другому процессу, в результате чего 
несколько процессов могут синхронизироваться, используя один семафор. Суще¬ 
ствуют вызовы для выполнения на семафоре операций ир и сіоип, они имеют несколь¬ 
ко странные имена: Ве1еа$е5етарІтоге (ир) и Маі1:Рог5іпд1е0Ь)ес1: (сіоип). Функции 
Маі1:Рог5іпд1еОЬ)ес1: также можно задать интервал времени, по истечении которого 
ждущий изменения состояния семафора поток будет отпущен, даже если семафор 
останется равным 0 (хотя использование таймеров приводит к конфликтам). 

Мьютексы также представляют собой объекты ядра, используемые для синх¬ 
ронизации, но они проще семафоров, так как не содержат счетчиков. По существу, 
они являются блокировками, для работы с которыми используются функции АРІ 
Маі1:Рог5іпд1е0Ь)ес1: и РеІеазеМиѣех. Как и дескрипторы семафоров, дескрипторы 
мьютексов можно скопировать и передать другому процессу, так что потоки раз¬ 
личных процессов смогут иметь доступ к одному и тому же мьютексу. 

Третий механизм синхронизации основан на критических секциях (которые 
назывались критическими областями в других главах этой книги). Критические 
секции подобны мьютексам, но отличаются тем, что они связаны с адресным про¬ 
странством создавшего их потока. Поскольку критические секции не являются 
объектами ядра, у них нет дескрипторов или дескрипторов защиты и они не могут 
передаваться от одного процесса другому. Блокирование и разблокирование 
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выполняется функциями ЕпІегСгі Іісаі Зесѣіоп и І_еаѵеСп ІісаіЗесЬі оп соответствен¬ 
но. Поскольку эти функции АРІ в основном выполняются в пространстве пользо¬ 
вателя и обращаются к системным вызовам в ядро, только когда требуется блоки¬ 
рование потока, они работают быстрее, чем мьютексы. 

В последнем механизме синхронизации используются объекты ядра, называе¬ 
мые событиями, которые бывают двух видов: сбрасываемые вручную и сбрасыва¬ 
емые автоматически. Каждое событие может находиться в одном из двух состоя¬ 
ний: установленном и сброшенном. Поток может ждать какого-либо события с 
помощью функции МаіІРогЗіпдІеОЬаесІ;. Если другой поток вызывает событие при 
помощи функции ЗеІЕѵепІ;, результат зависит от типа события. Если событие яв¬ 
ляется сбрасываемым вручную, то все ждущие его потоки отпускаются, а событие 
остается в установленном состоянии, пока его кто-либо не сбросит при помощи 
функции КезеІЕѵепІ;. В случае сбрасываемого автоматически события отпускается 
только один ожидающий его поток, а событие тут же сбрасывается. Кроме функ¬ 
ции ЗеІЕѵепІ; существует также функция Риі зеЕѵеггЬ, отличающаяся от первой функ¬ 
ции тем, что если этого события никто не ждет, событие все равно само сбрасыва¬ 
ется и, таким образом, пропадает впустую. При использовании функции ЗеІЕѵепІ; 
событие, которого никто не ждет, напротив, остается в установленном состоянии, 
так что как только какой-либо поток обратится к функции МаіЕРогЗіпдІ еОЬЛес!, он 
будет тут же отпущен, после чего событие сбросится. 

События, мьютексы и семафоры могут иметь имена и храниться в файловой 
системе, подобно именованным каналам. Несколько процессов могут синхрони¬ 
зироваться друг с другом, открывая одно и то же событие, мьютекс или семафор, 
что проще, чем создание такого объекта одним процессом и передача другим про¬ 
цессам дубликата дескриптора, хотя такой способ, конечно, также возможен. 

Интерфейс \Ѵіп32 АРІ содержит около 100 вызовов, работающих с процесса¬ 
ми, потоками и волокнами. Значительное количество этих вызовов в той или иной 
мере имеет отношение к межпроцессному взаимодействию. Некоторые из обсуж¬ 
давшихся выше функций, а также некоторые другие важные функции приведены 
в табл. 11.10. 


Таблица 11 . 10 . Некоторые функции ѴѴіп32 АРІ для управления процессами, 
потоками и волокнами 


Функция ѴѴіп32 АРІ 

Описание 

СгеаІеРгосезз 

Создать новый процесс 

СгеаІеТПгеасі 

Создать новый поток в существующем процессе 

СгеаГеРіЬег 

Создать новое волокно 

ЕхіГРгосезз 

Завершить текущий процесс и все его потоки 

ЕхіШігеасі 

Завершить этот поток 

ЕхДРіЬег 

Завершить это волокно 

ЗеГРгіогіІуСІазз 

Задать класс приоритета для процесса 

ЗеШігеасіРгіогіГу 

Задать приоритет для потока 

СгеаГеЗетарЬоге 

Создать новый семафор 

СгеаІеМШех 

Создать новый мьютекс 

ОрепЗетарПоге 

Открыть существующий семафор 


продолжение 
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Таблица 11.10 ( продолжение) 


Функция ѴѴіп32 АРІ Описание 


ОрепМШех 

ѴѴаііРогЗіпдІеОЬіесі 

ѴѴаіТРогМиІІІрІеОЬІесІз 

РиІзеЕѵепІ 

ВеІеазеМиІех 

ВеІеазеЗетарМоге 

ЕпІегСгіІісаІЗесііоп 

І_еаѵеСгіІісаІ5есІіоп 


Открыть существующий мьютекс 
Блокироваться на одном семафоре, мьютексе и т. д. 

Блокироваться на множестве объектов, чьи дескрипторы 
перечисляются 

Перевести событие в сигнализирующее состояние, а затем вернуть 
в несигнализирующее 

Освободить мьютекс, чтобы другой поток мог его захватить 
Увеличить на единицу счетчик семафора 
Захватить блокировку для критической секции 
Освободить блокировку для критической секции 


Большинство вызовов из табл. 11.10 либо обсуждались выше, либо должны гово¬ 
рить сами за себя. Снова обращаю ваше внимание, что не все они являются системны¬ 
ми вызовами. Как уже упоминалось, операционная система \ѴіпсІо\Ѵ5 2000 ничего 
не знает о волокнах. Они полностью реализованы в пространстве пользователя. 
Поэтому функция СгеаІеРіЬег выполняет свою работу целиком в пространстве пользо¬ 
вателя, не обращаясь к системным вызовам (разве что только с просьбой выделить 
ей память). Многие другие вызовы \Ѵіп32 также обладают подобным свойством, 
включая уже упомянутые функции ЕпІегСгіІісаІЗесІіоп и ІеаѵеСгіІісаІЗесІіоп. 

Реализация процессов и потоков 

Процессы и потоки имеют большее значение и являются более сложными, чем за¬ 
дания и волокна, поэтому мы сконцентрируем наше внимание на них. Процесс со¬ 
здается другим процессом при помощи вызова интерфейса \Ѵт32 СгеаІеРгосезз. 
Этот вызов обращается (в режиме пользователя) к процедуре в динамической биб¬ 
лиотеке кегпеІ32.(Ш, которая в несколько этапов создает процесс, используя при 
этом множество системных вызовов и других действий. 

1. Указанный в качестве параметра исполняемый файл изучается и открывает¬ 
ся. Если это корректный исполняемый файл формата Р08ІХ, 08/2, 16-раз- 
рядной системы \ѴіпсІо\Ѵ5 или М8-Э08, то для него устанавливается специ¬ 
альное окружение. Если это корректный .ехе файл 32-разрядного интерфейса 
\Ѵіп32, в реестре проверяется, не является ли этот файл особенным в каком- 
либо смысле (например, должен выполняться под контролем отладчика). 
Все эти действия выполняются в режиме пользователя внутри кете132.(Ш. 

2. Выполняется обращение к системному вызову МІСгеаІеРгосезз, чтобы создать 
пустой объект процесса и поместить его в пространство менеджера объек¬ 
тов. Создаются объект ядра и объект исполняющей системы. Кроме того, 
менеджер процессов создает для объекта управляющий блок процесса и ини¬ 
циализирует его идентификатором процесса, квотами, маркером доступа 
и различными другими полями. Также создается объект секции, чтобы сле¬ 
дить за адресным пространством процесса. 

3. Когда динамическая библиотека кетеІ32.(Ш снова получает управление, она 
обращается к еще одному системному вызову, МХгеаІеТНгеасІ, чтобы создать 
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начальный поток. Для потока создаются стек режима пользователя и стек 
режима ядра. Размер стека указан в заголовке исполняемого файла. 

4. Затем библиотека кете132.(Ш посылает подсистеме окружения \Уіп32 со¬ 
общение, в котором содержится информация о новом процессе, и передает 
ей дескрипторы процесса и потока. Данные о процессе и потоке помещают¬ 
ся в таблицы подсистемы, в результате чего у нее оказывается полный спи¬ 
сок всех процессов и потоков. Затем подсистема отображает курсор в виде 
стрелки с песочными часами, чтобы сообщить пользователю, что что-то про¬ 
исходит, но курсор может использоваться. Когда процесс обращается к сво¬ 
ему первому вызову графического интерфейса пользователя, как правило, 
чтобы создать окно, курсор удаляется (если обращения к вызову не посту¬ 
пает, курсор удаляется через 2 с). 

5. В этот момент поток готов к работе. Он начинается с запуска процедуры 
системы поддержки исполнения программ для завершения инициализации. 

6. Процедура системы поддержки исполнения программ устанавливает прио¬ 
ритет потока, сообщает загруженным библиотекам БЬЬ о появлении ново¬ 
го потока, а также выполняет другую рутинную работу. Наконец, она запус¬ 
кает код основной программы потока. 

Создание потока также состоит из нескольких этапов, но мы не будем вда¬ 
ваться в эти подробности. Сначала работающий процесс обращается к функции 
СгеаІеТЬгеасІ, которая вызывает процедуру внутри кете132.(Ш. Эта процедура вы¬ 
деляет в вызывающем процессе память для стека режима пользователя, а затем 
обращается к системному вызову Ы^СгеаСеТІдгеасІ, чтобы создать объект потока для 
исполняющей системы, проинициализировать его, а также создать и проинициа- 
лизировать блок управления потоком. И в этом случае уведомляется подсистема 
\Уіп32, а информация о потоке помещается в ее таблицы. Затем поток начинает 
работу с собственной инициализации. 

Когда создается процесс или поток, исходному процессу возвращается дескрип¬ 
тор, который можно использовать для запуска, остановки, уничтожения и провер¬ 
ки созданного процесса или потока. Владелец дескриптора может передать его дру¬ 
гому процессу защищенным способом. Эта техника применяется, чтобы отладчики 
могли иметь полный контроль над управляемыми ими процессами. 

Планирование 

В операционной системе \Ѵіпсіо\ѵз 2000 нет центрального потока планирования. 
Вместо этого, когда какой-либо поток не может более выполняться, этот поток сам 
переходит в режим ядра и запускает планировщика, чтобы определить, на какой 
поток переключиться. Текущий поток выполняет программу планировщика при 
одном из следующих условий: 

1) поток блокируется на семафоре, мьютексе, событии, операции ввода-выво¬ 
да и т. д; 

2) поток сигнализирует каким-либо объектом (например, выполняет операцию 
ир на семафоре); 

3) истекает квант времени работающего потока. 
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В случае 1 поток уже работает в режиме ядра, чтобы выполнить операцию с 
объектом диспетчера или ввода-вывода. Возможно, он не может продолжать 
работу, поэтому он должен сохранить свой контекст, запустить программу плани¬ 
ровщика, чтобы выбрать своего преемника, и загрузить контекст этого потока, что¬ 
бы запустить его. 

В случае 2 поток также находится в ядре. Однако после сигнализирования 
объектом он, определенно, может продолжать работу, так как эта операция никог¬ 
да не приводит к блокированию. Тем не менее поток должен запустить процедуру 
планировщика, чтобы посмотреть, нет ли среди готовых к работе потока с более 
высоким приоритетом. Если такой поток есть, происходит переключение на этот 
поток, так как операционная система \Уіпс1о\Ѵ5 2000 является системой с при¬ 
оритетным прерыванием (то есть переключение потока может произойти в любой 
момент, а не только тогда, когда у текущего потока закончится выделенный ему 
квант времени). 

В случае 3 происходит эмулированное прерывание с Передачей управления 
в ядро. При этом поток также запускает процедуру планировщика, чтобы опреде¬ 
лить, какой поток следует запустить после текущего потока. Если все остальные 
потоки в данный момент окажутся заблокированными, планировщик может про¬ 
должить выполнение текущего потока, выделив ему новый квант времени. В про¬ 
тивном случае происходит переключение потока. 

Планировщик также вызывается при еще двух условиях: 

1. Завершается операция ввода-вывода. 

2. Истекает ожидание таймера. 

В первом случае какой-нибудь поток, возможно, ожидал окончания этой опе¬ 
рации ввода-вывода и теперь может продолжить свою работу. Необходимо опре¬ 
делить, должен ли этот поток прервать выполнение текущего потока, так как по¬ 
токам не гарантируется минимальный рабочий интервал времени. Планировщик 
не запускается во время работы самой процедуры обработки прерываний (так как 
при этом прерывания могут оказаться запрещенными на слишком долгий срок). 
Вместо этого отложенный вызов процедуры БРС устанавливается в очередь и вы¬ 
полняется немного позднее, после того как процедура обработки прерываний 
закончит свою работу. Во втором случае поток выполнил операцию сіоип на сема¬ 
форе или блокировался на каком-либо другом объекте, но установленное время 
ожидания истекло. И в этом случае обработчик прерываний должен установить 
ИРС в очередь, чтобы она не была запущена во время работы обработчика преры¬ 
ваний. Если в результате тайм-аута поток оказался готовым к работе, будет запу¬ 
щен планировщик, и если ничего более важного в данный момент нет, будет вы¬ 
полнен отложенный вызов процедуры. 

Теперь мы подходим к самому алгоритму планирования. Интерфейс \Уіп32 АРІ 
содержит два вызова, предоставляющих процессам возможность влиять на пла¬ 
нирование потоками. Алгоритм планирования в большой степени определяется 
этими вызовами. Во-первых, есть вызов ЗеЕРгіогіЕуСІ Э55, устанавливающий класс 
приоритета всех потоков вызывающего процесса. К допустимым значениям при¬ 
оритета относятся: реального времени, высокий, выше нормы, нормальный, ниже 
нормы и неработающий. 
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Во-вторых, имеется вызов ЗеСТІігеасіРгіогНу, устанавливающий относительный 
приоритет некоторого потока (возможно, но не обязательно, потока, обращающе¬ 
гося к этому вызову) по сравнению с другими потоками данного процесса. При¬ 
оритет может иметь следующие значения: критичный ко времени, самый высокий, 
выше нормы, нормальный, ниже нормы, самый низкий и неработающий. Таким 
образом, шесть классов процессов и семь классов потоков могут образовать 42 ком¬ 
бинации. Эта информация поступает на вход алгоритма планирования. 

Планировщик работает следующим образом. В системе существует 32 уровня 
приоритета, пронумерованные от 0 до 31. 42 комбинации отображаются на эти 
32 приоритета в соответствии с табл. 11.11. Число в таблице определяет базовый 
приоритет потока. Кроме того, у каждого потока есть текущий приоритет, кото¬ 
рый может быть выше (но не ниже) базового приоритета и о котором мы скажем 
несколько слов. 

Таблица 11.11. Преобразование приоритетов ѴѴІп32 в приоритеты ѴѴіпсІоѵѵз 2000 

Приоритеты Классы приоритетов процессов ѴѴіп32 


потоков ѴѴіп32 

Реального 

времени 

Высокий 

Выше 

нормы 

Нормальный 

Ниже 

нормы 

Бездействующий 

Критичный 

31 

15 

15 

15 

15 

15 

ко времени 

Самый высокий 

26 

15 

12 

10 

8 

6 

Выше нормы 

25 

14 

11 

9 

7 

5 

Нормальный 

24 

13 

10 

8 

6 

4 

Ниже нормы 

23 

12 

9 

7 

5 

3 

Самый низкий 

22 

11 

8 

6 

4 

2 

Неработающий 

16 

1 

1 

1 

1 

1 


Чтобы использовать эти приоритеты для планирования, система содержит мас¬ 
сив из 32 элементов, соответствующих приоритетам от 0 до 31, полученных из 
табл. 11.11. Каждый элемент массива указывает на начало списка готовых пото¬ 
ков с соответствующим приоритетом. Базовый алгоритм планирования состоит из 
процедуры сканирования массива от приоритета 31 до приоритета 0. Как только 
найден непустой элемент, выбирается поток в начале очереди и запускается на 
один квант времени. Когда квант истекает, поток направляется в конец очереди 
своего приоритета, а следующим выбирается поток в начале очереди. Другими сло¬ 
вами, когда есть несколько готовых потоков с наивысшим уровнем приоритета, они 
запускаются поочередно, получая каждый по одному кванту времени. Если гото¬ 
вых потоков нет, запускается бездействующий поток. 

Следует отметить, что при планировании не учитывается, какому процессу 
принадлежит тот или иной поток. То есть планировщик не выбирает сначала про¬ 
цесс, а затем поток в этом процессе. Он смотрит только на потоки. Он даже не зна¬ 
ет, какой поток какому процессу принадлежит. На многопроцессорной системе 
каждый центральный процессор сам занимается планированием своих потоков 
при помощи массива приоритетов. Чтобы гарантировать, что в каждый момент 
времени лишь один центральный процессор работает с массивом, используется 
спин-блокировка. 
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Массив заголовков очередей показан на рис. 11.8. Из рисунка видно, что в дей¬ 
ствительности существует четыре категории приоритетов: реального времени, 
пользовательские, нулевой и бездействующий, равный -1. Об этом следует ска¬ 
зать несколько слов. Приоритеты с 16 по 31 называются приоритетами реального 
времени, но они таковыми не являются. Выполняющимся с этими приоритетами 
потокам не дается никаких гарантий и никакие сроки исполнения не учитывают¬ 
ся. Это просто более высокие приоритеты, чем приоритеты с 0 по 15. Однако 
приоритеты с 16 по 31 зарезервированы для самой системы и для потоков, кото¬ 
рым такой высокий приоритет явно задаст системный администратор. Обычные 
пользователи не могут запускать потоки со столь высокими приоритетами, и суще¬ 
ствует веская причина для этого. Если бы пользовательский процесс мог работать 
с приоритетом более высоким, чем, скажем, поток клавиатуры или мыши, то дли¬ 
тельная работа такого высокоприоритетного потока без операций ввода-вывода 
(например, в цикле) повесила бы всю систему. 



Приоритет 


Системные 

приоритеты 


Пользовательские 
приоритеты ^ 


Поток 

обнуления 

страниц 



Пустой поток 


Рис. 11.8. ѴѴіпсІоѵѵз 2000 поддерживает 32 приоритета для потоков 


Пользовательские потоки работают с приоритетами от 1 до 15. Устанавливая 
приоритеты процесса и потока, пользователь может отдавать преимущество тому 
или иному потоку. Нулевой поток работает в фоновом режиме и съедает все про¬ 
цессорное время, на которое больше никто не претендует. Его работа заключается 
в обнулении страниц для менеджера памяти. Его роль в системе будет обсуждать¬ 
ся ниже. Если и у этого потока нет работы, работает пустой поток. Однако он не 
является полноценным потоком. 

Со временем для улучшения производительности системы в базовом алгорит¬ 
ме планирования было сделано несколько усовершенствований. При определен¬ 
ных условиях текущий приоритет пользовательского потока может быть поднят 
операционной системой выше базового приоритета, но никогда не может быть уста¬ 
новлен выше приоритета 15. Так как массив на рис. 11.8 основан на текущем при- 
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оритете, изменение этого приоритета изменяет поведение алгоритма планирова¬ 
ния. Для потоков с приоритетами 15 и выше никогда не делается никаких измене¬ 
ний приоритета. 

Когда же увеличивается приоритет потока? Во-первых, когда завершается 
операция ввода-вывода и освобождает ожидающий ее поток, приоритет потока 
увеличивается, чтобы дать шанс этому потоку быстрее запуститься и снова запус¬ 
тить операцию ввода-вывода. Суть в том, чтобы поддерживать занятость устройств 
ввода-вывода. Величина, на которую увеличивается приоритет, зависит от устрой¬ 
ства ввода-вывода. Как правило, это 1 для диска, 2 для последовательной линии, 
6 для клавиатуры и 8 для звуковой карты. 

Во-вторых, если поток ждал семафора, мьютекса или другого события, то когда 
он отпускается, к его приоритету прибавляется две единицы, если это поток перед¬ 
него плана (то есть процесс, управляющий окном, которому в данный момент 
направляется ввод с клавиатуры), и одна единица в противном случае. Таким 
образом, интерактивный процесс получает преимущество перед большой толпой 
других процессов на уровне 8. Наконец, если поток графического интерфейса 
пользователя просыпается, потому что стал доступен оконный ввод, он также по¬ 
лучает прибавку приоритета по той же самой причине. 

Эти увеличения приоритета не вечны. Они незамедлительно вступают в силу, 
но если поток использует весь свой следующий квант времени, он теряет один 
пункт и перемещается на одну очередь вниз в массиве приоритетов. Если он 
использует еще один полный квант, он перемещается еще на один уровень ниже 
и т. д., пока он не достигнет своего базового уровня, где останется до тех пор, пока 
ему снова не будет прибавлен приоритет. Очевидно, если поток претендует на 
хорошее обслуживание, он должен действовать очень активно. 

Есть еще один случай, при котором система изменяет приоритеты потоков. 
Представьте, что два потока работают вместе в задаче типа «производитель-потре¬ 
битель». Работа производителя труднее, поэтому он получает более высокий при¬ 
оритет, например 12, а потребитель получает приоритет 4. В определенный момент 
производитель заполняет до отказа общий буфер и блокируется на семафоре, как 
показано на рис. 11.9, а. 



Выполняет операцию боѵѵп 
на семафоре и блокируется 


Семафор 



Готов 


ѳ 


' Хотел бы выполнить операцию 
ир на семафоре, но никогда 
не получает управление 


а б 

Рис. 11 .9. Пример инверсии приоритета 



886 


Глава 11. Рассмотрение конкретных случаев: ѴѴІпсІоѵѵз 2000 


Прежде чем потребитель снова получит шанс поработать, посторонний про¬ 
цесс с приоритетом 8 приходит в состояние готовности и получает управление, 
(рис. 11.9, б). Этот поток сможет работать столько, сколько захочет, так как его 
приоритет выше приоритета потребителя, а производитель, хоть и с большим 
приоритетом, заблокирован. При таких условиях производитель никогда снова не 
получит управления, пока поток с приоритетом 8 не остановится. 

В операционной системе \Ѵіпс1о\ѵ5 2000 эта проблема решается при помощи 
большой кувалды. Система следит, сколько времени прошло с тех пор, когда гото¬ 
вый к работе поток запускался в последний раз. Если какой-либо поток превысит 
определенный интервал времени, он получает на два кванта времени приоритет 15. 
Это может помочь разблокировать производителя. После двух квантов прибавка 
приоритета резко убирается. Вероятно, лучшим решением было бы наказывать 
потоки, которые полностью используют свои кванты снова и снова. В конце кон¬ 
цов, проблему создает не поток, умирающий от голода, а жадный поток. Эта про¬ 
блема хорошо известна под названием инверсии приоритетов. 

Аналогичная проблема возникает в том случае, когда поток с приоритетом 16 
захватывает мьютекс и долго не получает управления, в результате чего более 
важные системные потоки, ждущие этого мьютекса, умирают от истощения. Эту 
проблему можно устранить, если разрешить потоку, которому на короткое время 
требуется мьютекс, просто запрещать планирование на время использования 
мьютекса. На многопроцессорных системах следует применять спин-блокировку. 

Напоследок следует сказать пару слов о кванте. В системе \Ѵіпс1о\У5 2000 
Ргоіеззіопаі длительность кванта по умолчанию равна 20 мс; на однопроцессорных 
серверах его значение равно 120 мс; на многопроцессорных системах используют¬ 
ся различные другие варианты в зависимости от частоты процессора. Более ко¬ 
роткий квант улучшает работу интерактивных процессов, тогда как более длин¬ 
ный квант снижает количество переключений контекста и тем самым увеличивает 
производительность. Именно в этом смысл правой колонки табл. 11.2. Значения 
по умолчанию при желании могут быть увеличены в 2, 4 или 6 раз. Кстати, вели¬ 
чина кванта была выбрана более десяти лет назад и не менялась с тех пор, хотя 
компьютеры за это время стали быстрее более чем на порядок. Вероятно, эти чис¬ 
ла можно было бы без ущерба уменьшить в 5 или 10 раз и, возможно, получить 
при этом лучшее время отклика для интерактивных потоков в сильно загружен¬ 
ной системе. 

Последняя модификация алгоритма планирования заключается в том, что 
когда окно становится окном переднего плана, все его потоки получают более 
длительные кванты времени. Величина прибавки интервала времени хранится 
в системном реестре. Таким образом, поток получает больше процессорного вре¬ 
мени, и, соответственно, достигается лучшее обслуживание для окна, перемещен¬ 
ного на передний план. 

Эмуляция М8-Э08 

Одна из задач проектирования системы \Ѵіпс1о\ѵз 2000 была унаследована от ЫТ: 
постараться поддержать по возможности большое (в разумных пределах) количе¬ 
ство программ для М5-Б05. Эта цель принципиально отличалась от задачи, 
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поставленной перед создателями системы \Ѵіпс1о\У5 98: в ней должны были рабо¬ 
тать все старые программы для МЗ-БОЗ (от себя добавим: неважно, насколько 
плохо они работали). 

Операционная система \Ѵіпс1о\ѵз 2000 запускает старые программы в полнос¬ 
тью защищенном окружении. Когда запускается программа, написанная для сис¬ 
темы МЗ-БОЗ, запускается нормальный процесс \Ѵіп32, в который загружается 
эмулятор МЗ-ООЗ піѵсіт (ЫТ Ѵігіиаі БОЗ МасЬіпе — виртуальная машина БОЗ 
для ИТ), сканирующий программу МЗ-ООЗ и выполняющий ее системные вызо¬ 
вы. В системе МЗ-БОЗ всего лишь 1 Мбайт оперативной памяти на процессоре 
Іпіеі 8088 и до 16 Мбайт с переключением банков и другими трюками на процес¬ 
соре Іпіеі 80286. Поэтому можно без особого риска поместить процесс піѵсіт в стар¬ 
шие адреса виртуального адресного пространства, где программа не сможет к нему 
адресоваться. Эта ситуация показана на рис. 11.10, 



Рис. 11.10. Запуск старых программ для МЗ-008 в системе ѴѴІпсІоѵѵз 2000 


Когда программа МЗ-ВОЗ выполняет обычные команды процессора, она может 
работать на голой аппаратуре, так как процессор Репііит полностью поддерживает 
наборы команд процессоров Іпіеі 8088 и Іпіеі 80286. Самое интересное начинает¬ 
ся, когда программа МЗ-ВОЗ собирается выполнить операцию ввода-вывода или 
обратиться к операционной системе. Корректно написанная программа просто 
выполняет системный вызов. Рассчитывая на корректное поведение, эмулятор 
піѵсіт инструктирует систему \Ѵіпс1о\ѵз 2000 перенаправлять все системные вызо¬ 
вы ему. В результате системный вызов просто «отскакивает» от операционной 
системы и перехватывается эмулятором (шаги 1 и 2 на рис. 11.10). Такой метод 
иногда называют использованием трамплина (батута). 

Получив управление, эмулятор определяет, что пытается сделать программа, 
и обращается к вызову \Ѵіп32 для выполнения требуемой работы (шаги 3 и 4 на 
рис. 11.10). Пока программа ведет себя корректно и лишь обращается к легальным 
системным вызовам МЗ-БОЗ, этот метод прекрасно работает. Неприятность в том, 
что некоторые старые программы, написанные для работы в системе МЗ-БОЗ, 
обходят операционную систему и напрямую обращаются к видеопамяти, напря¬ 
мую читают порты клавиатуры и т. д., то есть выполняют действия, недопустимые 
в защищенной среде. Если такое некорректное поведение программы приводит 
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к прерываниям, есть надежда, что эмулятор сумеет определить, чего хочет про¬ 
грамма, и сможет эмулировать это действие. Если же определить намерения 
программы не удастся, программа просто уничтожается, так как задача стопроцент¬ 
ной эмуляции старых операционных систем никогда не ставилась при проектиро¬ 
вании \Ѵіпс1о\Ѵ5 2000. 

Загрузка ѴѴіпсІоѵѵз 2000 

Прежде чем операционная система \Ѵіпс1о\ѵ5 2000 сможет начать работу, она долж¬ 
на загрузиться. Процесс загрузки создает начальные процессы. В данном разделе мы 
кратко обсудим процесс загрузки операционной системы \Ѵіпс1о\ѵз 2000. С точки 
зрения аппаратного обеспечения, процесс загрузки состоит из чтения первого сек¬ 
тора первого диска (главной загрузочной записи), после чего прочитанной програм¬ 
ме передается управление, как было описано в разделе «Форматирование дисков» 
главы 5. Эта короткая программа на ассемблере считывает таблицу разделов, что¬ 
бы определить, в каком разделе содержится загружаемая операционная система. 
Найдя раздел с операционной системой, начальный загрузчик считывает первый 
сектор этого раздела, называемый загрузочным сектором, и передает управление 
ему. Программа, содержащаяся в загрузочном секторе, считывает корневой ката¬ 
лог своего дискового раздела, находит в нем файл псШг(еще одно археологическое 
свидетельство того, что \Ѵіпс1оѵѵ$ 2000 на самом деле представляет собой ЫТ). Если 
этот файл удается найти, он загружается в память и ему передается управление. 
Программа піЫг загружает операционную систему \Ѵіпс1о\Ѵ5 2000. Существует не¬ 
сколько версий загрузочного сектора в зависимости от формата раздела (ЕАТ-16, 
ЕАТ-32 или ЫТЕ8). При установке \Ѵіпс1оѵѵ$ 2000 на диск записываются соответ¬ 
ствующие версии главной загрузочной записи и загрузочного сектора. 

Затем программа піЫг считывает файл Вооі.іпі, представляющий собой един¬ 
ственный файл с информацией о конфигурации, не содержащейся в реестре. Он 
хранит в себе списки всех версий файлов каІЯІІ и піоакеті.ехе, которые могут быть 
загружены с данного раздела диска. В этом файле также содержатся такие пара¬ 
метры, как количество центральных процессоров и оперативной памяти, сколько 
памяти отводить процессу пользователя (2 или 3 Гбайт), а также на какой часто¬ 
те работают часы реального времени. Затем программа піЫг выбирает и загру¬ 
жает файлы каІЯІІ и піткеті.ехе, а также файл ЬооІѵЯЯІІ, представляющий собой 
видеодрайвер по умолчанию. Он обеспечивает вывод на дисплей во время процес¬ 
са загрузки. После этого программа піМг считывает реестр, чтобы найти драйверы, 
необходимые для завершения загрузки (например, драйверы клавиатуры и мыши, 
а также десятки других драйверов, требуемых для управления различными микро¬ 
схемами на материнской плате). Наконец, загрузчик считывает все эти драйверы 
и передает управление программе піозкеті.ехе. 

После запуска операционная система выполняет некоторые общие процедуры 
инициализации, а затем вызывает компоненты исполняющей системы, чтобы те 
также выполнили собственную инициализацию. Например, менеджер объектов 
подготавливает свое пространство имен, чтобы другие компоненты могли обра¬ 
щаться к нему и добавлять свои объекты в пространство имен. Многие компонен¬ 
ты также выполняют определенные действия, относящиеся к их функциям, так, 
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менеджер памяти настраивает начальные таблицы страниц, а менеджер р1и§-апс1- 
ріау определяет, какие устройства ввода-вывода присутствуют, и загружает их 
драйверы. Вся загрузка состоит из десятков этапов, в течение которых на экране 
отображается полоса прогресса, растущая по мере выполнения очередных этапов. 
Последний этап заключается в создании первого настоящего пользовательского 
процесса, сеансового менеджера зтзз.ехе. Как только этот процесс начинает рабо¬ 
ту, загрузка считается законченной. 

Сеансовый менеджер представляет собой «родной» процесс операционной 
системы \Ѵіпс1о\ѵ5 2000. Он обращается к истинным системным вызовам и не 
пользуется вызовами подсистемы окружения \Ѵіп32, которая в тот момент еще 
даже не работает. Одной из его первоочередных обязанностей является запуск этой 
подсистемы (сзгзз.ехе). Он также считывает с диска ульи реестра и узнает из них, 
что еще он должен сделать. Как правило, его работа заключается в помещении мно¬ 
жества объектов в пространство имен менеджера объектов, создании дополнитель¬ 
ных файлов подкачки и открытии нужных БЬЬ. Завершив свою работу, сеансо¬ 
вый менеджер создает демон регистрации тгпіо^оп.ехе. 

В этот момент операционная система загружена и работает. Теперь пора запус¬ 
тить служебные процессы (демоны в пространстве пользователя) и позволить 
пользователям регистрироваться в системе. Сначала тпІо§оп.ехе создает менед¬ 
жера аутентификации ( Ьавв.ехе ), а затем запускает родительский процесс всех слу¬ 
жебных процессов ( $егѵісе$.ехе ). Последний процесс по информации, хранящейся 
в реестре, определяет, какие демоны в пространстве пользователя нужно запустить 
и в каких файлах они находятся. После этого он приступает к их созданию. Такие 
демоны показаны на рис. 11.2. Как правило, уже после того, как первый пользова¬ 
тель зарегистрировался в системе, но еще до того, как он успел в ней что-либо 
сделать, в операционной системе \Ѵіпс1о\ѵ5 2000 наблюдается высокая активность 
с большим количеством обращений к диску. Это программа вегѵісев.ехе создает 
системные службы. Кроме того, она загружает все оставшиеся, еще не загружен¬ 
ные, драйверы устройств. Иерархия начальных процессов и некоторых типичных 
служб показана в табл. 11.12. Процессы, расположенные выше линии, запускают¬ 
ся всегда. Процессы, помещенные в нижней части таблицы, представляют собой 
примеры служб, которые могут быть запущены. 

Программа тпіороп.ехе также отвечает за регистрацию всех пользователей 
в системе. Диалоговое окно отображается отдельной программой ттфпаЛІІ, чтобы 
другие производители программного обеспечения могли заменить стандартную 
процедуру регистрации с вводом имени и пароля идентификацией отпечатков 
пальцев или еще чем-нибудь. После успешного входа пользователя в систему про¬ 
грамма тпіороп.ехе получает из реестра профиль пользователя и определяет по 
нему, какую оболочку запустить. Многие пользователи этого не осознают, но стан¬ 
дартный рабочий стол \Ѵіпс1о\ѵ5 представляет собой просто программу ехріогег.ехе 
(Проводник), у которой настроены некоторые параметры. При желании пользо¬ 
ватель может выбрать в качестве оболочки другую программу, включая команд¬ 
ную строку или даже редактор 1 ѴоЫ, для чего ему нужно просто отредактировать 
реестр. Однако редактирование реестра — занятие не для слабых духом. Одна 
ошибка может сделать систему незагружаемой. 
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Таблица 11.12. Процессы, запускаемые на стадии загрузки 

Процесс 

Описание 

ісііе 

Не настоящий процесс, а жилище пустого потока 

зузіет 

Создает зтзз.ехе и файлы подкачки, читает реестр, 
открывает ОЦ. 

зтзз.ехе 

Первый истинный процесс; много инициализации; создает 

СЗГ55 и ѵѵіпіодоп 

сзгзз.ехе 

Процесс подсистемы ѴѴІП32 

ѵѵіпіодоп.ехе 

Демон регистрации 

Ізазз.ехе 

Менеджер аутентификации 

зѳгѵісез.ехѳ 

Смотрит в реестр и запускает службы 

Сервер принтера 

Позволяет удаленному заданию использовать принтер 

Файловый сервер 

Обслуживает запросы к локальным файлам 

Демон Іеіпеі 

Обеспечивает удаленную регистрацию 

Обработчик входящей 
электронной почты 

Принимает и хранит входящую почту 

Обработчик входящих 
факсов 

Принимает и печатает входящие факсы 

Распознаватель 0№ 

Сервер службы Интернета 

Регистратор событий 

Регистрирует различные события системы 

Менеджер ріид- 
апб-ріау 

Сканирует аппаратуру, чтобы определить устройства, 
присутствующие в системе 


Управление памятью 

В операционной системе \Ѵіпсіо\ѵз 2000 крайне сложная система виртуальной па¬ 
мяти. В \Ѵіпс1о\У5 2000 есть множество функций \Ѵіп32 для использования вирту¬ 
альной памяти и часть исполняющей системы плюс шесть выделенных потоков 
ядра для управления ею. В следующих разделах мы рассмотрим основные поня¬ 
тия, вызовы \Ѵіп32 и, наконец, реализацию управления памятью. 

Основные понятия 

В операционной системе \Ѵіпсіо\ѵз 2000 у каждого пользовательского процесса есть 
собственное виртуальное адресное пространство. Виртуальные адреса 32-разряд- 
ные, поэтому у каждого процесса 4 Гбайт виртуального адресного пространства. 
Нижние 2 Гбайт за вычетом около 256 Мбайт доступны для программы и данных 
процесса; верхние 2 Гбайт защищенным образом отображаются на память ядра. 
Страницы виртуального адресного пространства имеют фиксированный размер 
(4 Кбайт на компьютере с процессором Репііит) и подгружаются по требованию. 

Конфигурация виртуального адресного пространства для трех пользовательских 
процессов в слегка упрощенном виде показана на рис. 11.11. Белым цветом на ри¬ 
сунке изображена область приватных данных процесса. Затененные области пред¬ 
ставляют собой память, совместно используемую всеми процессами. Нижние и 
верхние 64 Кбайт каждого виртуального адресного пространства в обычном состо- 
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янии не отображаются на физическую память. Это делается преднамеренно, что¬ 
бы облегчить перехват программных ошибок. Недействительные указатели часто 
имеют значение 0 или -1, и попытки их использования в системе \Ѵіпс1о\ѵ5 2000 
вызовут немедленное прерывание вместо чтения или, что еще хуже, записи слова 
по неверному адресу. Однако когда запускаются старые программы МБ-БОЗ в ре¬ 
жиме эмуляции, нижние 64 Кбайт могут отображаться на физическую память. 


Процесс А 


Процесс В 


4 Гбайт 


2 Гбайт 


0 


і Невыгружаемый пул 
і Выгружаемый пул 

і Таблицы страниц 
! процесса А 

г Стек, данные и т. д. 
г НА1_ + ОЗ 

і Системные данные 

Ц._ 

I 

I 

■ Приватные данные 
! и программа 
I процесса А 


! Невыгружаемый пул 
і Выгружаемый пул 

I-- 

і Таблицы страниц 
! процесса В 

г.- 

і Стек, данные и т. д. 

' НА1_ + ОЗ 

і Системные данные 

I 

' Приватные данные 
і и программа 
I процесса В 


Нижние и верхние 
64 Кбайт недействительны 


Процесс С 

■— 

1 -———— 

і Невыгружаемый пул 

Выгружаемый пул 

Г Таблицы страниц 
! процесса С 

і --- 

' Стек, данные и т. д. 

' НАЬ + 05 

1 — -—— 

і Системные данные 

■ Приватные данные 
і и программа 

1 процесса С 


Рис. 11.11. Конфигурация виртуального адресного пространства 
для трех пользовательских процессов 


Начиная с адреса 64 К, могут располагаться приватные данные и программа 
пользователя. Они могут занимать почти 2 Гбайт. Последний фрагмент этих 2 Гбайт 
памяти содержит некоторые системные указатели и таймеры, используемые со¬ 
вместно всеми пользователями в режиме доступа «только чтение». Отображение 
этих данных в эту область памяти позволяет всем процессам получать к ним дос¬ 
туп без лишних системных вызовов. 

Верхние 2 Гбайт виртуального адресного пространства содержат операционную 
систему, включая код, данные и выгружаемый и невыгружаемый пулы (использу¬ 
емые для объектов и т. д.). Верхние 2 Гбайт используются совместно всеми про¬ 
цессами, кроме таблиц страниц, которые являются индивидуальными для каждо¬ 
го процесса. Верхние 2 Гбайт процессам в режиме пользователя запрещены для 
записи, а по большей части также запрещены и для чтения. Причина, по которой 
они размещаются здесь, заключается в том, что когда поток обращается к систем¬ 
ному вызову, он переключается в режим ядра, но остается все тем же потоком. Если 
сделать всю операционную систему и все ее структуры данных (как и весь пользо¬ 
вательский процесс) видимыми в адресном пространстве потока, когда он переклю¬ 
чается в режим ядра, то отпадает необходимость в изменении карты памяти или 
выгрузке кэша при входе в ядро. Все, что нужно сделать, — это переключиться на 
стек режима ядра. Платой за более быстрые системные вызовы при данном подхо- 
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де является уменьшение приватного адресного пространства для каждого процес¬ 
са. Большим базам данных уже сейчас становится тесно в таких рамках, вот поче¬ 
му в версиях \Ѵіпс1о\Ѵ5 2000 Асіѵапсесі зегѵег и Оаіасепіег Зегѵег есть возможность 
использования 3 Гбайт для адресного пространства пользовательских процессов. 

Каждая виртуальная страница может находиться в одном из трех состояний: 
свободном, зарезервированном и фиксированном. Свободная страница не исполь¬ 
зуется в настоящий момент, и ссылка на нее вызывает страничное прерывание. 
Когда процесс запускается, все его страницы находятся в свободном состоянии, 
пока программа и исходные данные не будут отображены на их адресное простран¬ 
ство. Как только данные или программа отображаются на страницу, страница на¬ 
зывается фиксированной. Обращение к фиксированной странице преобразуется 
при помощи аппаратного обеспечения виртуальной памяти и завершается успехом, 
если эта страница находится в оперативной памяти. В противном случае происхо¬ 
дит страничное прерывание, операционная система находит требуемую страницу 
на диске и считывает ее в оперативную память. 

Виртуальная страница может также находиться в зарезервированном состоя¬ 
нии, в таком случае эта страница не может отображаться, пока резервирование не 
будет явно удалено. Например, когда создается новый поток, в виртуальном ад¬ 
ресном пространстве резервируется 1 Мбайт пространства для стека, но фиксиру¬ 
ется только одна страница. Такая техника означает, что стек может вырасти до 
1 Мбайт без опасения, что какой-либо другой поток захватит часть необходимого 
непрерывного виртуального адресного пространства. Помимо состояния (свободная, 
зарезервированная или фиксированная), у страниц есть также и другие атрибуты, 
например страница может быть доступной для чтения, записи или исполнения. 

При выделении фиксированным страницам места резервного хранения исполь¬ 
зуется интересный компромисс. Простая стратегия в данном случае состояла бы в 
отведении для каждой фиксированной страницы одной страницы в файле подкач¬ 
ки во время фиксации страницы. Это означало бы, что всегда есть место, куда за¬ 
писать каждую фиксированную страницу, если потребуется удалить ее из памяти. 
Недостаток такой стратегии заключается в том, что при этом может потребовать¬ 
ся файл подкачки размером со всю виртуальную память всех процессов. На боль¬ 
шой системе, которой редко требуется выгрузка виртуальной памяти на диск, та¬ 
кой подход приведет к излишнему расходованию дискового пространства. 

Чтобы не тратить пространство на диске понапрасну, в \Ѵіпс1о\ѵз 2000 фиксиро¬ 
ванным страницам, у которых нет естественного места хранения на диске (напри¬ 
мер, страницам стека), не выделяются страницы на диске до тех пор, пока не настанет 
необходимость их выгрузки на диск. Такая схема усложняет систему, так как во 
время обработки страничного прерывания может понадобиться обращение к фай¬ 
лам, в которых хранится информация о соответствии страниц, а чтение этих файлов 
может вызвать дополнительные страничные прерывания. С другой стороны, для 
страниц, которые никогда не выгружаются, пространства на диске не требуется. 

Подобный выбор (усложнение системы или увеличение производительности 
и дополнительные функции), как правило, разрешается в пользу последнего, так 
как достоинства лучшей производительности и большего числа функций очевид¬ 
ны, тогда как недостатки усложнения системы (сложность поддержки и увеличе¬ 
ние частоты сбоев) бывает сложно учесть. У свободных и зарезервированных стра- 
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ниц никогда не бывает теневых страниц на диске и обращение к ним всегда приво¬ 
дит к страничным прерываниям. 

Теневые страницы на диске организованы в один или несколько файлов под¬ 
качки. Может быть организовано до 16 файлов подкачки, для повышения произ¬ 
водительности операций ввода-вывода они могут быть распределены по отдель¬ 
ным дискам, которых также может быть до 16. У каждого файла есть начальный 
размер и максимальный размер, до которого он может вырасти при необходимос¬ 
ти. Эти файлы могут сразу быть созданы максимального размера во время уста¬ 
новки системы, чтобы уменьшить вероятность их сильной фрагментации, но с по¬ 
мощью панели управления позднее можно создать новые файлы. Операционная 
система следит за тем, какие виртуальные страницы на какую часть файла подкач¬ 
ки отображаются. Страницы, содержащие исполняемый текст программ, не дуб¬ 
лируются в файлах подкачки. В файлах подкачки хранятся только изменяемые 
страницы. 

В \Ѵіпс1о\ѵ5 2000, как и во многих версиях ІЖІХ, файлы могут отображаться 
напрямую на области виртуального адресного пространства (то есть занимать мно¬ 
жество соседних страниц). После того как файл отображен на адресное простран¬ 
ство, он может читаться и писаться при помощи обычных команд обращения к 
памяти. Отображаемые на память файлы реализуются тем же способом, что и фик¬ 
сированные страницы, но теневые страницы хранятся не в файле подкачки, а в 
файле пользователя. Поэтому при отображении файла на память версия файла, 
находящаяся в памяти, может отличаться от дисковой версии (вследствие записи 
в виртуальное адресное пространство). Однако когда отображение файла прекра¬ 
щается или файл принудительно выгружается на диск, дисковая версия снова при¬ 
водится в соответствие с последними изменениями файла в памяти. 

В ^іп<іо\Ѵ8 2000 два и более процессов могут одновременно отображать на свои 
виртуальные адресные пространства, возможно, в различные адреса, одну и ту же 
часть одного и того же файла, как показано на рис. 11.12. (Файл ІіЪАй на рисунке 
отображен одновременно на два адресных пространства.) Читая и записывая сло¬ 
ва памяти, процессы могут общаться друг с другом и передавать друг другу ин¬ 
формацию с очень большой скоростью, так как копирование при этом не требует¬ 
ся. У различных процессов могут быть различные права доступа. Поскольку все 
процессы, использующие отображаемый на память файл, совместно используют 
одни и те же страницы, изменения, произведенные одним процессом, немедленно 
становятся видимыми для всех остальных процессов, даже если файл на диске еще 
не был обновлен. Также предпринимаются меры, благодаря которым процесс, от¬ 
крывающий файл для нормального чтения, видит текущие страницы в ОЗУ, а не 
устаревшие страницы с диска. 

Следует отметить, что при совместном использовании двумя программами од¬ 
ного файла БЬЬ может возникнуть проблема, если одна из программ изменит ста¬ 
тические данные файла. Если не предпринять специальных действий, то другой 
процесс увидит измененные данные, что, скорее всего, не соответствует намерени¬ 
ям этого процесса. Эта проблема решается таким способом: все отображаемые стра¬ 
ницы помечаются как доступные только для чтения, хотя в то же время некоторые 
из них тайно помечаются как в действительности доступные и для записи. Когда 
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к такой странице происходит обращение операции записи, создается приват¬ 
ная копия этой страницы и отображается на память. Теперь в эту страницу мож¬ 
но писать, не опасаясь задеть других пользователей или оригинальную копию на 
диске. Такая техника называется копированием при записи. 


Васкіпд зіоге оп сЯзк 



Ргод 1 .ехе Ргод2.ехе 

Рис. 11.12. Отображаемые на память области с их теневыми страницами на диске 


Следует отметить, что и в случае, если текст программы отображается на два 
адресных пространства по различным адресам, также возникают проблемы с адре¬ 
сацией. Что будет, если первой командой будет ,1МР 300? Если процесс 1 отобразит 
эту программу на адрес 65 536, программа легко может быть настроена на новый 
адрес заменой этой команды командой .1МР 65836. Но что будет, если второй про¬ 
цесс отобразит эту программу с адреса 131 072? Вместо передачи управления по 
адресу 131 372 команда ,1МР 65836 передаст его по адресу 65 836, после чего вся про¬ 
грамма будет работать неверно. Решение заключается в использовании в совмест¬ 
но используемой программе только относительных смещений вместо абсолютных 
виртуальных адресов. К счастью, у большинства компьютеров есть команды, ис¬ 
пользующие относительную адресацию, а также команды, использующие абсолют¬ 
ную адресацию. Компиляторы могут использовать относительную адресацию, но 
они должны знать заранее, какой тип адресации использовать. Как правило, отно¬ 
сительная адресация не используется постоянно, так как при этом снижается эф¬ 
фективность программы. Тип используемой адресации обычно задается ключом 
компиляции. Техника создания участка программы, который может работать не¬ 
зависимо от адреса без настройки, называется РІС (Розіііоп Іп<3ереп<3еп1 С обе — 
позиционно-независимый код). 
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Несколько лет назад, когда 16-разрядные (или 20-разрядные) виртуальные ад¬ 
реса были стандартом, но у машин были мегабайты физической памяти, приду¬ 
мывались самые разнообразные трюки, позволяющие программам использовать 
больше физической памяти, чем помещалось в адресное пространство. Часто при¬ 
менялось так называемое переключение банков памяти, заключавшееся в том, что 
программа заменяла один физический блок памяти в своем адресном простран¬ 
стве другим блоком. Когда появились 32-разрядные машины, программисты ду¬ 
мали, что теперь у них никогда не будет недостатка в адресном пространстве. Они 
ошибались. Эта проблема снова возвращается. Большим программам часто быва¬ 
ет нужно больше, чем 2 или 3 Гбайт пользовательского адресного пространства, 
предоставляемого им системой \Уіп(1оѵѵ$ 2000. Таким образом, переключение бан¬ 
ков памяти возвращается под названием оконных расширений адреса. Это свой¬ 
ство позволяет программам отображать в адресное пространство пользователя то 
одну, то другую большую область памяти (особенно за пределами 4-гигабайтной 
границы). Поскольку это имеет смысл только на серверах, у которых более 2 Гбайт 
физической памяти, мы отложим обсуждение этой проблемы до выхода следую¬ 
щего издания данной книги (к тому времени даже настольные компьютеры будут 
ощущать ограничение 32-разрядных адресов). 


Системные вызовы управления памятью 

Интерфейс \Ѵт32 АРІ содержит множество функций, позволяющих процессу 
явно управлять своей виртуальной памятью. Наиболее важные функции перечис¬ 
лены в табл. 11.13. Все они работают с областью, состоящей либо из одной страни¬ 
цы, или с двумя или более страницами, располагающимися последовательно в вир¬ 
туальном адресном пространстве. 

Таблица 11.13. Основные функции ѴѴіп32 АРІ для управления виртуальной памятью 
в ѴѴіпсІоѵѵз 2000 


Функция Описание 


ѴІПиаІАІІос 

ѴіПиаІРгее 

ѴігІиаІРгоІесі 

ѴігіиаЮиегу 

ѴігІиаНоск 

ѴІПиаІІІлІоск 

СгеаІеРіІеМаррілд 

МарѴіеѵЮНчІе 

ІІптарѴіеѵѵСНРІІе 

ОрепРІІеМаррілд 


Зарезервировать или фиксировать область 
Освободить область или отменить фиксацию области 
Изменить режим доступа (чтение/запись/выполнение) к области 
Узнать состояние области 

Сделать область резидентной в памяти (то есть запретить ее выгрузку) 
Разрешить выгрузку области 

Создать объект отображаемого файла и (по желанию) присвоить ему имя 
Отобразить файл (часть файла) на адресное пространство 
Удалить отображаемый файл из адресного пространства 
Открыть созданный ранее объект отображаемого файла 


Первые четыре функции АРІ используются для выделения и освобождения 
областей виртуального адресного пространства, изменения их режима защиты и 
получения информации о текущем режиме. Выделенные области всегда начина¬ 
ются с 64-килобайтных границ, что сводит к минимуму проблемы переноса систе- 
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мы на компьютеры будущего с большим размером страниц (до 64 Кбайт), чем у 
нынешних машин. Количество выделенного адресного пространства может быть 
меньше, чем 64 Кбайт, но оно должно состоять из целого числа страниц. Следую¬ 
щие две функции АРІ дают процессу возможность зафиксировать страницы в па¬ 
мяти, запрещая их выгрузку, и отменить их фиксацию. Такая возможность может 
быть полезной, например, для программы реального времени. Операционной сис¬ 
темой накладывается предел на количество фиксируемых страниц. На самом деле 
фиксированные страницы могут быть удалены из памяти, но только в том случае, 
когда весь процесс выгружается на диск. Когда процесс снова загружается в па¬ 
мять, все его зафиксированные страницы также загружаются, прежде чем поток 
получает управление. Хотя они и не показаны в табл. 11.13, в операционной сис¬ 
теме \Ѵіік1о\ѵ8 2000 также есть функции АРІ, позволяющие процессу получать до¬ 
ступ к виртуальной памяти других процессов, которыми он может управлять (то 
есть тех, от которых у него есть дескриптор). 

Последние четыре функции АРІ, перечисленные в таблице, управляют ото¬ 
бражением файлов на адресное пространство памяти. Чтобы отобразить файл 
на адресное пространство памяти, сначала следует создать объект отображения 
(см. табл. 11,6) при помощи функции С геаѣеРі 1 еМаррі пд. Эта функция возвращает 
дескриптор объекта отображения, а также может ввести имя объекта в файловую 
систему, чтобы другие процессы могли пользоваться этим объектом. Следующие 
две функции включают и выключают отображение файла на адресное простран¬ 
ство памяти. Последняя функция в таблице может использоваться процессом для 
отображения на память файла, уже использующегося подобным образом другим 
процессом. Таким образом, несколько процессов могут совместно использовать об¬ 
ласти своих виртуальных адресных пространств. Эта техника позволяет им запи¬ 
сывать данные в ограниченные области памяти других процессов. 

Реализация управления памятью 

В операционной системе УАшіоѵѵз 2000 поддерживается подгружаемое по тре¬ 
бованию одинарное линейное 4-гигабайтное адресное пространство для каждого 
процесса. Сегментация в любой форме не поддерживается. Теоретически размер 
страниц может быть любой степенью двух, вплоть до 64 Кбайт. На компьютерах 
с процессором Репііит страницы имеют фиксированный размер в 4 Кбайт. На 
компьютерах с процессором Ііапіит они могут быть 8 или 16 Кбайт. Кроме того, 
сама операционная система может использовать страницы по 4 Мбайт, чтобы 
снизить размеры таблицы страниц. 

В отличие от планировщика, выбирающего отдельные потоки для запуска и не 
заботящегося о процессах, менеджер памяти занимается исключительно процесса¬ 
ми и не беспокоится о потоках. В конце концов, именно процессы, а не потоки вла¬ 
деют адресным пространством, которым занимается менеджер памяти. При выде¬ 
лении области виртуального адресного пространства (на рис. 11.12 процессу А было 
выделено четыре области) менеджер памяти создает для нее описатель виртуаль¬ 
ной памяти (ѴАБ, Ѵігіиаі Асісігезз Безспріог), в котором хранится информация 
о диапазоне отображаемых адресов, файле резервного хранения и смещении в 
файле для отображаемой части файла, а также режим доступа. Когда происходит 
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обращение к первой странице, создается каталог таблиц страниц, а указатель на 
нее помещается в описатель виртуальной памяти. Адресное пространство полнос¬ 
тью описывается списком своих описателей виртуальной памяти. Такая схема по¬ 
зволяет поддерживать несплошные адресные пространства, так как неиспользуе¬ 
мые области между отображаемыми областями не потребляют ресурсов. 

Обработка страничных прерываний 

В операционной системе \Ѵіпс1о\ѵ5 2000 опережающая подкачка страниц не ис¬ 
пользуется ни в каком виде. Когда запускается процесс, в памяти не находится ни 
одной страницы процесса. При каждом страничном прерывании происходит пе¬ 
редача управления ядру (которое понимается так, как изображено на рис. 11.2). 
Ядро формирует машинно-независимый описатель, в который помещается инфор¬ 
мация о том, что случилось, и передает его части исполняющей системы, выпол¬ 
няющей функции менеджера памяти. Менеджер памяти проверяет полученный 
описатель на корректность. Если страница, вызвавшая прерывание, попадает в фик¬ 
сированную или зарезервированную область, он ищет адрес в списке описателей 
виртуальной памяти, находит (или создает) таблицу страниц и ищет в ней соот¬ 
ветствующий элемент. 

Элементы таблицы страниц различаются в разных архитектурах. Для компью¬ 
теров с процессором Репііиш элемент таблицы для отображаемой страницы пока¬ 
зан на рис. 11.13. У неотображаемых страниц также есть записи в таблице, но их 
формат несколько отличается. Например, если неотображаемая страница должна 
быть обнулена перед употреблением, этот факт отражается в таблице. 
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С: Гповальная страница ѴѴі: Сквозная запись (без кэширования) 

для всех процессов I): К странице возможен доступ 

Г: Большая (4 Мбайт) страница в режиме пользователя 

О: Страница «грязная» ѴѴ: Запись в страницу разрешена 

А: К странице были обращения V: Действительная запись таблицы 

С: Кэширование разрешено/запрещено 

Рис. 11 . 13 . Запись таблицы для отображаемой страницы 
на компьютере с процессором Репііит 

Для алгоритма подкачки наиболее важными битами записи таблицы страниц 
являются биты А и И. Они устанавливаются аппаратно и позволяют отслеживать 
наличие обращений к странице и записи в нее с момента последнего сброса этих 
битов. Страничные прерывания подразделяются на пять категорий: 

1. Страница, к которой было обращение, не является фиксированной. 

2. Произошло нарушение защиты. 

3. Запись в совместно используемую страницу. 

4. Стеку требуется дополнительная память. 

5. Страница, к которой было обращение, является фиксированной, но в насто¬ 
ящий момент она не загружена в память. 
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Первый и второй случаи представляют собой фатальные ошибки, которые не 
могут быть исправлены или проигнорированы. У третьего случая симптомы схо¬ 
жи со вторым (попытка записи в страницу, для которой разрешено только чтение), 
но лечение этого случая возможно. В этом случае страница копируется в новый 
физический страничный блок, после чего для копии разрешается чтение/запись. 
Таким образом, работает копирование при записи. (Если совместно используемая 
страница помечена как доступная для записи во всех процессах, использующих ее, 
страничного прерывания при записи в такую страницу не возникает и копии при 
записи не возникает также.) В четвертом случае требуется выделение нового стра¬ 
ничного блока и его отображение. Однако правила безопасности требуют, чтобы 
эта страница содержала только нули, что не позволяет новому процессу узнать, чем 
занимался предыдущий владелец страницы. Таким образом, нужно найти страни¬ 
цу, содержащую одни нули или, если это невозможно, нужно выделить другой 
страничный блок и обнулить его на месте. Наконец, пятый случай представляет 
собой нормальное страничное прерывание. Менеджер памяти находит страницу 
на диске и считывает ее в память. 

Фактический механизм получения и отображения страниц весьма стандартен, 
поэтому мы не станем обсуждать здесь этот вопрос. Следует только отметить, что 
операционная система М^іпс1о\ѵ5 2000 не читает отдельные страницы прямо с дис¬ 
ка. Вместо этого считывается несколько последовательных страниц, как правило, 
от 1 до 8, чтобы минимизировать количество обращений к диску. Для страниц, со¬ 
держащих код программы, используются серии из большего числа страниц, чем 
при считывании страниц данных. 

Алгоритм замещения страниц 

Замена страниц происходит следующим образом. Система пытается поддерживать 
определенное количество свободных страниц в памяти, чтобы, когда произойдет 
страничное прерывание, свободная страница могла быть найдена немедленно, без 
необходимости сначала записать несколько других страниц на диск. В результате 
применения такой стратегии большинство страничных прерываний удовлетворя¬ 
ются при помощи всего одной дисковой операции (чтения страницы с диска), хотя 
иногда приходится выполнять две операции (запись на диск «грязной» страницы, 
после чего с диска читается требуемая страница). 

Конечно, страницы, пополняющие список свободных страниц, должны откуда- 
то поступать. Поэтому настоящая работа алгоритма замещения страниц характери¬ 
зуется тем, как эти страницы забираются у процессов и помещаются в список сво¬ 
бодных страниц (в действительности существует четыре списка свободных страниц, 
но в данный момент для простоты будем считать, что это один список; детали мы 
обсудим позднее). Посмотрим теперь, как операционная система ^іпс1о\ѵ5 2000 
освобождает страницы. Начнем с того, что в системе подкачки активно использует¬ 
ся понятие рабочего набора. У каждого процесса (не у каждого потока) есть рабо¬ 
чий набор. Этот набор состоит из отображенных страниц, находящихся в памяти, 
при обращении к которым, следовательно, не происходит страничных прерываний. 
Размер и состав рабочего набора, естественно, меняются по мере работы процесса. 

Рабочий набор каждого процесса описывается двумя параметрами: минималь¬ 
ным и максимальным размерами. Эти размеры не являются жесткими границами. 
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Процесс может иметь в памяти меньше страниц, чем значение нижней границы, 
или (при определенных обстоятельствах) больше установленного максимума. 
Вначале эти границы одинаковы для каждого процесса, но они могут меняться со 
временем. Начальное значение минимума по умолчанию находится в диапазоне 
от 20 до 50 страниц, а начальное значение максимума по умолчанию находится 
в диапазоне от 45 до 345 страниц, в зависимости от общего объема оперативной па¬ 
мяти. Значения по умолчанию могут быть изменены системным администратором. 

Если происходит страничное прерывание, а размер рабочего набора меньше 
минимального значения, то к рабочему набору добавляется страница. С другой 
стороны, если происходит страничное прерывание, а размер рабочего набора боль¬ 
ше максимального значения, то из рабочего набора (но не из памяти) изымается 
страница, чтобы выделить место для новой страницы. Этот алгоритм означает, что 
в операционной системе ^іпсіо\ѵ5 2000 используется локальный алгоритм, не по¬ 
зволяющий процессу получить слишком много памяти, что предотвращает при¬ 
чинение процессами ущерба друг другу. Однако система пытается настроить эти 
параметры. Например, если она замечает, что один процесс слишком активно за¬ 
нимается подкачкой (а остальные процессы нет), система может увеличить значе¬ 
ние максимального предела для рабочего набора; таким образом, алгоритм пред¬ 
ставляет собой смесь локальных и глобальных решений. Тем не менее существует 
абсолютный предел размера рабочего набора: даже если в системе работает всего 
один процесс, он не может занять последние 512 страниц, чтобы оставить немного 
оперативной памяти для новых процессов. 

Однако история на этом не заканчивается. Раз в секунду выделенный демон- 
поток ядра, называемый менеджером балансового множества, проверяет, доста¬ 
точно ли в системе свободных страниц. Если свободных страниц меньше, чем нуж¬ 
но, он запускает менеджер рабочих наборов, который исследует рабочие наборы 
и освобождает дополнительные страницы. Менеджер рабочих наборов сначала 
определяет порядок, в котором нужно исследовать процессы. В первую очередь 
страницы отнимаются у больших процессов, которые бездействовали в течение 
долгого времени. В последнюю очередь рассматривается процесс переднего плана. 

Затем менеджер рабочих наборов начинает исследование процессов в выбран¬ 
ном порядке. Если рабочий набор процесса в настоящий момент оказывается мень¬ 
ше своего нижнего предела или с момента последней инспекции число странич¬ 
ных прерываний у этого процесса было выше определенного уровня, то страницы 
у него не отнимаются. В противном случае менеджер рабочих наборов отнимает 
у процесса одну или несколько страниц. Количество забираемых у процесса стра¬ 
ниц довольно сложным образом зависит от общего объема ОЗУ, от того, насколько 
много требуется памяти текущим процессам, от того, как размер текущего рабоче¬ 
го набора соотносится с верхним и нижним пределами, а также от других парамет¬ 
ров. Все страницы рассматриваются по очереди. 

На однопроцессорной машине если бит обращений к странице сброшен, то 
счетчик, связанный со страницей, увеличивается на единицу. Если этот бит уста¬ 
новлен в единицу, счетчик обнуляется. После сканирования из рабочего набора 
удаляются страницы с наибольшими значениями счетчика. Поток продолжает изу¬ 
чать процессы, пока он не высвободит достаточного количества страниц, после чего 
он останавливается. Если полный перебор всех процессов не привел к освобож- 
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дению достаточного числа страниц, менеджер рабочих наборов начинает второй 
проход, на котором он уже «состригает» с процессов страницы более агрессивно, 
даже отнимая их при необходимости у процессов, размер рабочего набора кото¬ 
рых меньше минимального. 

На многопроцессорной системе алгоритм, основанный на проверке бита обраще¬ 
ний, уже не работает, так как хотя текущий центральный процессор не обращался 
в последнее время к данной странице, к ней могли обращаться другие централь¬ 
ные процессоры. Исследование же битов обращений всех центральных процессо¬ 
ров представляет собой слишком дорогое удовольствие. Поэтому бит обращений 
вообще не учитывается, а удаляются самые старые страницы. 

Следует отметить, что с точки зрения процедуры замены страниц операцион¬ 
ная система сама рассматривается как процесс. Она владеет страницами и у нее 
также есть рабочий набор. Этот рабочий набор тоже может быть уменьшен. Одна¬ 
ко некоторые части системы и невыгружаемый пул фиксированы в памяти и не 
могут выгружаться ни при каких обстоятельствах. 

Управление физической памятью 

Выше упоминалось, что в действительности в операционной системе \ѴіпсІо\ѵ$ 2000 
свободные страницы учитываются в четырех списках. Теперь настала пора позна¬ 
комиться с ними поближе. Каждая страница памяти находится в одном или не¬ 
скольких рабочих наборах или в одном из этих четырех списков, показанных на 
рис. 11.14, В списке чистых (резервных) и в списке грязных (модифицированных) 
страниц учитываются страницы, которые недавно были удалены из рабочих набо¬ 
ров, но все еще находятся в памяти и все еще ассоциированы с процессами, ис¬ 
пользовавшими их. Различие между ними заключается в том, что у чистых стра¬ 
ниц есть копия на диске, тогда как у модифицированных страниц таких копий нет, 
и эти страницы еще предстоит сохранить. В список свободных страниц входят чи¬ 
стые страницы, уже не ассоциированные ни с какими процессами. В список обну¬ 
ленных страниц входят страницы, не ассоциированные ни с какими процессами и 
заполненные нулями. Пятый список состоит из физически дефектных страниц 
памяти. Это гарантирует, что эти страницы ни для чего не используются. 

Страницы перемещаются между рабочими наборами и различными списками 
менеджером рабочих наборов и другими потоками-демонами ядра. Рассмотрим эти 
переходы. Когда менеджер рабочих наборов удаляет страницу из рабочего набора, 
страница попадает на дно списка чистых страниц или списка модифицирован¬ 
ных страниц в зависимости от своего состояния. Этот переход показан на рисунке 
как (1). В обоих списках хранятся действительные страницы, поэтому если про¬ 
исходит страничное прерывание и требуется одна из этих страниц, она удаляется 
из списка и возвращается в свой рабочий набор без операции дискового ввода- 
вывода (2). Когда процесс завершает свою работу, то все его страницы, которые 
не используются другими процессами, попадают в список свободных страниц (3). 
Эти страницы уже не ассоциированы с каким-либо процессом и не могут возвра¬ 
щаться в рабочие наборы по страничному прерыванию. 

Другие переходы вызываются другими демонами. Раз в 4 с запускается поток 
свопера в поисках процесса, все потоки которого бездействовали в течение опре¬ 
деленного интервала времени. Если ему удается найти такие процессы, он от- 
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крепляет стеки этих процессов и перемещает страницы процессов в списки чистых 
и грязных страниц (1). 


Требуется обнуленная страница (8) 



Страница удалена из рабочего набора (1) Процесс завершает работу (3) 


Рис. 11 . 14 . Списки страниц и переходы между ними 

Два других демона, демон записи отображенных страниц и демон записи моди¬ 
фицированных страниц, просыпаются время от времени, чтобы проверить, доста¬ 
точно ли чистых страниц. Если количество чистых страниц ниже определенного 
уровня, они берут страницы из верхней части списка модифицированных страниц, 
записывают их на диск, а затем помещают их в список чистых страниц (4). Пер¬ 
вый демон занимается записью в отображаемые файлы, а второй пишет страницы 
в файлы подкачки. В результате их деятельности грязные страницы становятся 
чистыми. 

Причина наличия двух демонов, занимающихся очисткой страниц, заключа¬ 
ется в том, что отображаемый на память файл может вырасти в результате записи 
в него. При этом росте потребуются новые свободные блоки диска. Отсутствие 
в памяти свободного места для записи в него страниц может привести к взаимо¬ 
блокировке. Второй поток может вывести ситуацию из тупика, записывая страни¬ 
цы в файл подкачки, который никогда не увеличивается в размерах. Никто и не 
говорил, что операционная система \Ѵішіо\уз 2000 проста. 

Обсудим другие переходы на рис. 11.14. Если процесс освобождает страницу, 
эта страница более не связана с процессом и может быть помещена в список свобод¬ 
ных страниц (5), если только она не используется совместно другими процессами. 
Когда страничное прерывание требует страничный блок, чтобы поместить в него 
страницу, которая должна быть считана, этот блок по возможности берется из 
списка свободных страниц (6). Не имеет значения, что эта страница может все еще 
содержать конфиденциальную информацию, так как вся она будет тут же целиком 
перезаписана. При увеличении стека ситуация складывается иная. В этом случае 
требуется пустой страничный блок и правила безопасности требуют, чтобы стра- 




902 


Глава 11. Рассмотрение конкретных случаев: ѴѴіпсІоѵѵз 2000 


ница содержала все нули. По этой причине другой демон ядра, поток обнуления 
страниц, работает с минимальным приоритетом (см. рис. 11.8), стирая содержимое 
страниц в списке свободных страниц и помещая их в список обнуленных стра¬ 
ниц (7). Когда центральный процессор простаивает и в списке свободных страниц 
есть страницы, поток обнуления страниц может обнулять их, так как обнуленная 
страница более полезна, чем просто свободная страница. 

Наличие всех этих списков приводит к необходимости принятия некоторых 
стратегических решений. Например, предположим, что страница должна быть счи¬ 
тана с диска, а список свободных страниц пуст. Теперь система вынуждена выби¬ 
рать между чистыми страницами из списка резервных страниц (которые могут 
потребоваться при очередном страничном прерывании) и пустыми страницами из 
списка обнуленных страниц (в результате работало обнулению страниц окажется 
выполненной впустую). Что лучше? Если центральный процессор ничем не занят, 
а обнуляющий страницы поток запускается часто, лучше взять обнуленную стра¬ 
ницу, так как в них нет недостатка. Однако если центральный процессор всегда 
занят, а диск по большей части простаивает, лучше взять страницу из списка 
резервных страниц, чтобы избежать излишних затрат процессорного времени на 
обнуление еще одной страницы, когда вырастет стек. 

Еще одна загадка. Насколько агрессивно должны демоны перемещать страни¬ 
цы из списка грязных страниц в список чистых страниц? Лучше иметь большое 
количество чистых страниц, чем большое количество грязных страниц, так как 
чистую страницу можно использовать мгновенно. Однако агрессивная политика 
очистки страниц означает большее количество операций дискового ввода-вывода; 
кроме того, есть шанс, что только что очищенная страница снова будет затребова¬ 
на в рабочий набор страничным прерыванием и снова испачкана. 

В операционной системе ѴУіпс1о\ѵз 2000 конфликты подобного рода разрешают¬ 
ся при помощи сложных эвристических алгоритмов, угадывания, учета предысто¬ 
рии, правил большого пальца и настройки параметров, устанавливаемых системным 
администратором. Более того, эта программа настолько сложна, что разработчики 
не любят менять в ней что-либо из-за страха сломать в системе какой-нибудь фраг¬ 
мент, структуру и назначение которого сегодня уже никто не понимает. 

Для отслеживания всех страниц и всех списков операционная система \Ѵіп- 
йо\ѵ5 2000 содержит базу данных страничных блоков, состоящую из записей по 
числу страниц ОЗУ (рис. 11.15). Эта таблица проиндексирована по номеру физи¬ 
ческого страничного блока. Записи таблицы имеют фиксированную длину, но для 
различных типов записей используются различные форматы (например, для дей¬ 
ствительных записей и для недействительных). Действительные записи содержат 
информацию о состоянии страницы, а также счетчик, хранящий число ссылок на 
эту страницу в таблицах страниц. Этот счетчик позволяет системе определить, ког¬ 
да страница уже более не используется. Если страница находится в рабочем наборе, 
то в записи также указывается номер рабочего набора. Кроме того, в записи содер¬ 
жится указатель на таблицу страниц, в которой есть указатель на эту страницу 
(если такая таблица страниц есть). Страницы, используемые совместно, учитыва¬ 
ются особо. Также запись содержит ссылку на следующую страницу в списке (если 
такая есть) и различные другие поля и флаги, такие как «страница читается», 
«страница пишется» и т. д. 
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Рис. 11 . 15 . Некоторые основные поля базы данных страничных блоков 


Итак, управление памятью представляет собой очень сложную подсистему 
с большим количеством структур данных, алгоритмов и эвристических методов. 
Во многом она является саморегулируемой, но у нее есть также множество кно¬ 
пок, на которые может нажимать системный администратор, чтобы влиять на про¬ 
изводительность системы. Увидеть эти кнопки и связанные указатели можно при 
помощи различных программ, входящих в состав упоминавшихся ранее разнооб¬ 
разных наборов инструментальных средств. Вероятно, важнее всего здесь помнить, 
что управление памятью в реальных системах намного сложнее простого алгорит¬ 
ма подкачки, вроде алгоритма часов или алгоритма старения. 


Ввод-вывод в ѴѴІпсІоѵѵз 2000 

Задача системы ввода-вывода \Ѵіпбо\ѵ5 2000 заключается в предоставлении кар¬ 
каса для эффективного управления широким спектром устройств ввода-вывода. 
К устройствам ввода относятся различные типы клавиатур, мышей, сенсорных 
панелей, джойстиков, сканеров, фотокамер, видеокамер, устройств чтения штрих¬ 
кода и микрофонов. Устройства вывода включают в себя мониторы, принтеры, 
плоттеры, бимеры, устройства записи СБ-КОМ и звуковые карты. К запоминаю¬ 
щим устройствам относятся накопители на гибких дисках, жесткие диски ШЕ 
и 5С5І, устройства чтения СБ-К.ОМ, устройства чтения ЭѴЭ, накопители на 
2ір-дисках и магнитофоны. Наконец, существуют еще такие устройства, как часы, 
сети, телефоны и видеокамеры со встроенными накопителями. Без всякого сомне¬ 
ния, в ближайшие годы будут изобретены новые устройства, поэтому операцион¬ 
ная система \Ѵіпс1о\ѵ5 2000 была спроектирована таким образом, чтобы к системе 
ввода-вывода можно было легко добавлять новые устройства. В следующих раз¬ 
делах мы рассмотрим некоторые вопросы, относящиеся к вводу-выводу. 
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Основные понятия 

Менеджер ввода-вывода родственен менеджеру р1и§-апсі-р1ау. Основная идея ме¬ 
ханизма р1и§-апсі-р1ау заключается в настраиваемой шине. За многие годы было 
разработано множество шин, включая РС Сагсі, РСІ, И5В, ІЕЕЕ 1394 и 5С5І, по¬ 
этому менеджер р1и§-апсі-р1ау может послать каждому разъему запрос и попросить 
устройство назвать себя. Определив, что за устройство подключено к шине, менед¬ 
жер р1и§-апй-р1ау выделяет для него аппаратные ресурсы, такие как уровни пре¬ 
рываний, находит необходимые драйверы и загружает их в память. При загрузке 
каждого драйвера для него создается объект драйвера. Для некоторых шин, напри¬ 
мер 5С5І, настройка происходит только во время загрузки операционной системы. 
Для других шин, таких как И5В и ІЕЕЕ 1394, она может производиться в любой 
момент, для чего требуется тесный контакт между менеджером р1и§-апсі-р1ау, драй¬ 
вером шины (который и выполняет настройку) и менеджером ввода-вывода. 

Менеджер ввода-вывода также тесно связан с менеджером энергопотребления. 
Менеджер энергопотребления может перевести компьютер в одно из шести состо¬ 
яний, которые можно примерно описать следующим образом: 

1. Полностью действующий. 

2. Режим сниженного энергопотребления-1: мощность, потребляемая централь¬ 
ным процессором, снижается, ОЗУ и кэш работают, возможен мгновенный 
переход в режим полного действия. 

3. Режим сниженного энергопотребления-2: центральный процессор и ОЗУ 
работают; кэш центрального процессора отключен; возможно продолжение 
работы с текущего значения счетчика команд. 

4. Режим сниженного энергопотребления-3: центральный процессор и кэш 
отключены; ОЗУ работает; возможен перезапуск с фиксированного адреса. 

5. Режим сниженного энергопотребления-3: центральный процессор и кэш 
отключены; ОЗУ работает; возможен перезапуск с фиксированного адреса. 

6. «Зимняя спячка»: центральный процессор, кэш и ОЗУ отключены; возмо¬ 
жен перезапуск из сохраненного на диске файла. 

7. Выключен: все выключено; требуется полная перезагрузка. 

Устройства ввода-вывода также могут находиться в различных состояниях. 
Включением и выключением этих устройств занимаются вместе менеджер энер¬ 
гопотребления и менеджер ввода-вывода. Обратите внимание, что состояния со 2 
по 6 используются, только если центральный процессор бездействовал в течение 
определенного времени. 

Это, может быть, кажется несколько удивительным, но формально все файло¬ 
вые системы представляют собой драйверы ввода-вывода. Обращения к блокам 
диска от пользовательских процессов сначала посылаются менеджеру кэша. Если 
менеджер кэша не может удовлетворить запрос из кэша, он просит менеджер вво¬ 
да-вывода вызвать драйвер соответствующей файловой системы, чтобы тот полу¬ 
чил требуемый блок с диска. 

Интересная особенность операционной системы \Ѵіпс1о\ѵ5 2000 заключается 
в поддержке динамических дисков. Эти диски могут распространяться на несколь¬ 
ко дисковых разделов или даже физических дисков и их можно переконфигури- 
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ровать на лету, без перезагрузки. Таким образом, логические тома более не привя¬ 
заны к отдельному разделу или даже одному жесткому диску, что позволяет полу¬ 
чить файловую систему, располагающуюся на нескольких дисках прозрачным для 
пользователя способом. 

Другой интересный аспект \Утс1о\ѵ5 2000 заключается в поддержке асинхрон¬ 
ного ввода-вывода. Поток может начать операцию ввода-вывода, а затем продол¬ 
жить выполнение параллельно с вводом-выводом. Такая возможность особенно 
важна для серверов. Существует множество способов, с помощью которых по¬ 
ток может определить, что операция ввода-вывода завершена. Один из способов 
состоит в создании в момент обращения к вызову ввода-вывода объекта события, 
а потом ожидания этого события. Другой способ заключается в указании очереди, 
в которую будет послано сообщение о завершении операции ввода-вывода. Третий 
способ заключается в предоставлении процедуры обратного вызова, к которой 
обращается система, когда операция ввода-вывода завершена. 


Вызовы ввода-вывода АРІ 

В операционной системе ^іпсіоѵѵз 2000 есть более 100 вызовов АРІ для работы 
с различными устройствами ввода-вывода, включая мыши, звуковые карты, те¬ 
лефоны, магнитофоны и т. д. Вероятно, наиболее важной является графическая 
система, для которой существует несколько тысяч вызовов ^іп32 АРІ. В разде¬ 
ле «Программное обеспечение вывода для \Уіпс1о\уз» главы 5 мы начали обсужде¬ 
ние графической системы \Ѵіп(Іо\ѵ§ 2000. Здесь мы продолжим обсуждение этой 
темы, рассмотрим несколько категорий интерфейса 1Ѵіп32 АРІ, в каждую из кото¬ 
рых входит множество вызовов. Краткий список категорий \Ѵіп32 АРІ приведен 
в табл. 11.14. Как упоминалось в главе 5, графическим функциям интерфейса 
^іп32 АРІ было посвящено множество 1500-страничных книг. 


Таблица 11 . 14 . Некоторые категории вызовов ѴѴіп32 АРІ 


Группа АРІ Описание 


Управление окнами 
Меню 

Диалоговые окна 
Рисование и черчение 
Текст 
Растровые 

изображения и значки 
Цвета и палитры 
Буфер обмена 
Ввод 


Создание, уничтожение окон, управление окнами 

Создание, уничтожение и добавление пунктов меню 

Отображение диалоговых окон и сбор информации 

Отображение точек, линий и геометрических фигур 

Вывод текста с использованием определенного шрифта, размера и цвета 

Отображение на экране растровых изображений и значков 

Управление набором доступных цветов 

Передача информации от одного приложения другому 

Получение информации от мыши и клавиатуры 


Существуют вызовы ЛѴІП32 для создания и уничтожения окон, а также для 
управления окнами. Есть множество стилей и параметров, которые могут указы¬ 
ваться при создании окна, такие как заголовки, рамки, цвета, размеры и полосы 
прокрутки. Окна могут быть фиксированные и перемещаемые, ■Постоянного или 
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изменяемого размера. Существуют вызовы для получения и изменения свойств 
окон, а также для отправления сообщений окнам. 

Многие окна содержат меню, поэтому существуют вызовы \Ѵіп32 АРІ для со¬ 
здания и удаления меню и строк меню. Динамические меню могут появляться и 
убираться с экрана. Пункты меню могут выделяться, затемняться и располагаться 
каскадом. 

Диалоговые окна появляются, чтобы информировать пользователя о каком- 
либо событии или чтобы задать ему вопрос. Они могут содержать кнопки, ползун¬ 
ки и текстовые поля. С диалоговыми окнами также могут быть ассоциированы зву¬ 
ки, например для предупреждающих сообщений. 

Существуют сотни функций для рисования и черчения, варьирующихся от за¬ 
дания одного пиксела до выполнения сложных операций с областями отсечения. 
Есть много вызовов для черчения линий и разнообразных замкнутых геометри¬ 
ческих фигур с возможностью детального управления текстурами, цветом, шири¬ 
ной и многими другими атрибутами. 

Другая группа вызовов относится к отображению текста. Вызов функции ТехІОиІ: 
для вывода текста очень прост. Все сложности, связанные с выводом текста, за¬ 
ключаются в управлении цветом, размерами точек, гарнитурой шрифта, шириной 
символов, глифами, величиной межзнакового интервала и другими деталями. 
К счастью, преобразование текста в растр выполняется автоматически. 

Растровые изображения представляют собой небольшие прямоугольные бло¬ 
ки пикселов, которые можно вывести на экран с помощью вызова ВИВН. Они ис¬ 
пользуются для значков и иногда для текста. Существует множество вызовов для 
создания, удаления значков, а также для управления ими. 

На многих дисплеях используется цветовой режим с использованием 256 или 
65 536 из 2 24 возможных цветов, что позволяет использовать для представления 
каждого пиксела всего один или два байта соответственно. В этих случаях тре¬ 
буется палитра цветов, чтобы указать, какие из 256 или 65 536 цветов доступны. 
Вызовы в этой группе позволяют создавать и удалять палитры, управлять ими, 
выбирать ближайший к заданному цвету доступный цвет, а также соблюдать со¬ 
ответствие цветов принтера цветам на экране. 

Многие программы \Ѵіпсіо\ѵз 2000 позволяют пользователям выбирать неко¬ 
торые данные (например, блок текста, фрагмент чертежа, набор ячеек в электрон¬ 
ной таблице), помещать их в буфер обмена и вставлять данные оттуда в другие 
приложения. Определено множество форматов буфера обмена, включая текст, 
растровые изображения, объекты и метафайлы. Последние представляют собой 
множества вызовов \Ѵіп32 рисования, что позволяет вырезать и копировать части 
рисунков. Данная группа вызовов \Ѵіп32 позволяет помещать данные в буфер об¬ 
мена, получать их из буфера обмена, а также управлять буфером обмена. 

Наконец, существуют вызовы \Ѵіп32, управляющие вводом данных. Среди этих 
вызовов нет вызовов для графических приложений, читающих входные данные с 
клавиатуры, так как графические приложения управляются событиями. Основная 
программа состоит из большого цикла, получающего входные сообщения. Когда 
пользователь вводит что-то интересное, программе посылается сообщение, содер¬ 
жащее введенную информацию. С другой стороны, существуют вызовы, относя¬ 
щиеся к мыши, такие как чтение координат (х, у) ее курсора и состояния кнопок. 
Некоторые вызовы ввода в действительности представляют собой вызовы выво- 
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да, например позволяющие выбрать изображение курсора мыши и управляющие 
перемещением курсора по экрану (эти действия представляют собой вывод на эк¬ 
ран). Неграфические приложения могут читать с клавиатуры. 


Реализация ввода-вывода 

О графических вызовах интерфейса \Ѵіп32 можно рассказывать бесконечно. Одна¬ 
ко теперь пора взглянуть на то, как менеджер ввода-вывода реализует графические 
и другие функции ввода-вывода. Основная функция менеджера ввода-вывода за¬ 
ключается в создании каркаса, в котором могут работать различные устройства вво¬ 
да-вывода. Основную структуру каркаса образуют набор независимых от устройств 
процедур для определенных аспектов ввода-вывода и набор загруженных драйве¬ 
ров для общения с устройствами. 

Драйверы устройств 

Чтобы гарантировать, что драйверы устройств хорошо работают с остальной час¬ 
тью системы \Ѵіпс1о\Ѵ5 2000, корпорация МісгозоЙ: определила для драйверов мо¬ 
дель \Ѵіпс1о\уз Огіѵег Мосіеі, которой драйверы устройств должны соответство¬ 
вать. Более того, корпорация МісгозоЙ также предоставляет набор инструментов, 
который должен помочь разработчикам драйверов в создании драйверов, соответ¬ 
ствующих модели \Ѵіпс1о\Ѵ5 Огіѵег Мосіеі. В данном разделе мы кратко рассмот¬ 
рим эту модель. Согласующиеся с ней драйверы должны удовлетворять всем сле¬ 
дующим требованиям (а также некоторым другим): 

1. Обрабатывать входящие запросы ввода-вывода, поступающие в стандарт¬ 
ном формате. 

2. Основываться на объектах, как и остальная часть системы \Ѵіпсіо\ѵз 2000. 

3. Позволять динамическое добавление или удаление устройств р1и§-апсі-р1ау. 

4. Допускать, когда это возможно, управление энергопотреблением. 

5. Допускать реконфигурацию в терминах использования ресурсов. 

6. Быть реентерабельными для возможности их использования на мультипро¬ 
цессорах. 

7. Обладать переносимостью между системами \Ѵіпс1о\ѵз 98 и \Ѵішіо\ѵз 2000. 

Запросы ввода-вывода передаются драйверам в виде стандартизированных 

пакетов, называемых ІКР (Іприі/оиіриі Кериезі Раскеі — пакет запроса ввода- 
вывода). Драйверы, согласующиеся с моделью \Ѵіпс1о\ѵ5 Бгіѵег Мосіеі, должны 
уметь обрабатывать пакеты ІКР. Драйвер должен поддерживать работу с объекта¬ 
ми, то есть поддерживать определенный список методов, к которым может обра¬ 
щаться остальная система. Он также должен корректно работать с другими объек¬ 
тами операционной системы \Ѵіпс1о\ѵ5 2000, доступ к которым осуществляется при 
помощи дескрипторов объектов. 

Драйверы, согласующиеся с моделью \Ѵіпс1о\Ѵ5 Огіѵег Мосіеі, должны полнос¬ 
тью поддерживать устройства р1и§-апй-р1ау. Это означает, что если устройство, 
управляемое драйвером, внезапно добавляется в систему или удаляется из систе¬ 
мы, драйвер должен быть готов к получению данной информации и корректной 
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реакции на эту информацию, даже в том случае, если устройство удаляется в момент 
обращения к нему. Также драйверы должны поддерживать управление энергопот¬ 
реблением для тех устройств, для которых это возможно. Например, если система 
решает, что теперь пора перейти в режим низкого энергопотребления, все драйве¬ 
ры должны поддерживать этот режим, чтобы сберегать энергию. Они также долж¬ 
ны поддерживать обратный переход в режим нормального функционирования. 

Драйвер должен быть настраиваемым, что означает отсутствие каких бы то ни 
было встроенных предположений о линиях прерываний или портах ввода-выво¬ 
да, используемых определенным устройством. Например, на компьютерах ІВМ РС 
и сменивших их моделях порт принтера более 20 лет имел адрес 0x378 и вряд ли 
будет изменен теперь. Но драйвер принтера, в который этот адрес жестко зашит, 
не является согласующимся с моделью \УіпсІо\Ѵ5 Огіѵег Мосіеі. 

Драйверы устройств также должны работать на мультипроцессорах, так как под¬ 
держка мультипроцессоров была заложена в операционную систему \УіпсІо\Ѵ5 2000 
при разработке. Это требование означает, это во время обработки драйвером запро¬ 
са от одного центрального процессора может прийти запрос от другого центрально¬ 
го процессора. Второй центральный процессор может начать выполнение програм¬ 
мы драйвера одновременно с первым центральным процессором. Драйвер должен 
функционировать корректно, даже когда он вызывается одновременно двумя и 
более центральными процессорами. Это означает, что доступ ко всем чувствитель¬ 
ным структурам данных должен предоставляться только внутри критических об¬ 
ластей. Простое предположение, что других обращений к драйверу не будет, пока 
не завершится обработка текущего обращения к нему, недопустимо. 

Наконец, драйверы, согласующиеся с моделью \УіпсІо\ѵ§ Огіѵег Мосіеі, должны 
работать не только в операционной системе \УіпсІо\ѵ$ 2000, но и в системе ДѴіп- 
сіо\ѵ8 98. Однако может оказаться необходимой перекомпиляция драйвера на каж¬ 
дой системе и использование команд препроцессора С, чтобы устранить зависи¬ 
мость от платформы. 

В операционной системе 1ЖІХ обращение к драйверам производится по номеру 
главного устройства. В \Ѵіпс1о\ѵ§ 2000 применяется другая схема. Во время загруз¬ 
ки операционной системы или в тот момент, когда в систему добавляется новое 
устройство р1и§-апс1-р1ау, поддерживающее установку без перезагрузки системы, 
операционная система \Ѵпк1о\ѵ8 2000 автоматически обнаруживает его и вызывает 
менеджер р1и§-апс1-р1ау. Менеджер р1и§-апс1-р1ау запрашивает у устройства назва¬ 
ние фирмы-производителя и номер модели устройства. Вооружившись данными 
сведениями, он ищет драйвер для данного устройства в определенном каталоге на 
жестком диске. Если этого драйвера нет, он отображает диалоговое окно, в котором 
пользователю предлагается вставить гибкий диск или СЭ-КОМ с драйвером. Ког¬ 
да драйвер обнаружен, он загружается в память. 

Каждый драйвер должен поставлять набор процедур, которые могут быть вы¬ 
званы для получения требуемого обслуживания. Первая процедура, называемая 
ОгіѵегЕпігу , инициализирует драйвер. Она вызывается сразу после загрузки драйве¬ 
ра. Процедура может создавать таблицы и структуры данных, но не должна обращать¬ 
ся к самому устройству. Она также заполняет некоторые поля объекта драйвера, 
созданного менеджером ввода-вывода при загрузке драйвера. Поля в объекте драй¬ 
вера включают указатели на все остальные процедуры, предоставляемые драйвером. 



Ввод-вывод в ѴѴІпбоѵѵз 2000 


909 


Кроме того, для каждого устройства, управляемого драйвером (например, для каждо¬ 
го диска ШЕ, управляемого драйвером диска ШЕ), создается объект устройства 
и инициализируется так, чтобы он указывал на объект драйвера. Эти объекты драй¬ 
веров помещаются в специальный каталог \??. При наличии объекта устройства 
можно легко найти объект драйвера и, таким образом, обращаться к его методам. 

Вторая процедура драйвера называется АсІсЮеѵісе. Она вызывается (менедже¬ 
ром р1и§-апсі-р1ау) всего один раз для каждого добавляемого устройства. После 
этого драйвер вызывается первым пакетом ШР, который устанавливает вектор 
прерываний и инициализирует аппаратуру. Кроме того, драйвер должен содержать 
процедуру обработки прерываний, различные процедуры, управляющие таймера¬ 
ми, путь быстрого ввода-вывода, управление ЭМА, позволять прервать исполня¬ 
ющийся текущий запрос и многое другое. В результате драйверы \ѴіпсІо\ѵ5 2000 
настолько сложны, что этой теме посвящено множество книг [50, 252, 345]. 

В операционной системе \Ѵіпйо\ѵ5 2000 драйвер должен сам выполнять всю 
работу, как, например, выполняет ее драйвер принтера на рис. 11.16. С другой сто¬ 
роны, в системе \Ѵіпс1о\ѵ5 2000 могут существовать стеки драйверов. Это означает, 
что запрос может проходить через целую последовательность драйверов, каждый 
из которых выполняет свою часть работы. Два таких драйвера также показаны на 
этом рисунке. 


Процесс пользователя 



Стек 

драйверов 


Рис. 11.16. Система ѴѴіпсІоѵѵв 2000 позволяет создавать драйверные стеки 
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Стеки драйверов позволяют отделить управление шиной от управления соб¬ 
ственно устройством. Управление шиной РСІ отличается большой сложностью, 
что вызвано большим количеством режимов и транзакций шины. Таким образом, 
отделение управления шиной от управления устройством, подключенным к данной 
шине, облегчает, работу по созданию драйвера. Программисту, пишущему драйвер 
устройства, более не нужно изучать вопрос управления шиной. Он может просто 
использовать стандартный драйвер шины, находящийся в стеке драйверов. У драй¬ 
веров РІ5В и 5С5І есть части, специфичные для конкретных устройств, и общая 
часть, для которой используются отдельные драйверы. 

Кроме того, стеки драйверов позволяют добавлять в стек драйверы-фильтры. 
Фильтрующий драйвер выполняет некоторые преобразования проходящих через 
них данных. Например, фильтрующий драйвер может сжать данные по пути к дис¬ 
ку или зашифровать их по дороге в сеть. Помещение драйверного фильтра в стек 
драйверов означает, что ни прикладная программа, ни настоящий драйвер устрой¬ 
ства не должны знать о присутствии фильтрующего драйвера и что фильтрующий 
драйвер работает автоматически для всех данных, поступающих с устройства или 
на устройство. 

Файловая система ѴѴіпсІоѵѵз 2000 

Операционная система \Ѵішіо\Ѵ5 2000 поддерживает несколько файловых систем, 
самыми важными из которых являются РАТ-16, РАТ-32 и ІЧТР8 (Nе \ѵ ТесЬпо 1 о^у 
Рііе ЗузГеш — файловая система новой технологии). Файловая система РАТ-16 — 
это старая файловая система М5-008. В ней используются 16-разрядные дисковые 
адреса, что ограничивает размер дискового раздела двумя гигабайтами. В файло¬ 
вой системе РАТ-32 используются 32-разрядные дисковые адреса и поддержива¬ 
ются дисковые разделы размером до 2 Тбайт. Система ШТ5 представляет собой 
новую файловую систему, разработанную специально для \Ѵіпс1о\ѵ5 ЫТ и перене¬ 
сенную в \Ѵіпс1о\У5 2000. В ней используются 64-разрядные дисковые адреса, та¬ 
ким образом, теоретически эта файловая система может поддерживать дисковые 
разделы размером до 2 64 байт, хотя по другим техническим причинам их размер 
ограничен меньшими размерами. Операционной системой \Ѵіпсіо\ѵ§ 2000 также 
поддерживаются файловые системы для СБ-КОМ и ОѴО, в которых разрешено 
только чтение. Одна и та же работающая операционная система может одновре¬ 
менно иметь доступ к нескольким файловым системам различного типа. 

В данной главе мы обсудим файловую систему 1МТР5, так как это современная 
файловая система, не обремененная необходимостью полной совместимости с фай¬ 
ловой системой М5-005, основанной на файловой системе СР/М, которая разра¬ 
батывалась для 8-дюймовых гибких дисков более 20 лет назад. Времена изменились, 
и 8-дюймовые гибкие диски уже не считаются современными. Устарели и файло¬ 
вые системы для этих дисков. Кроме того, файловая система 1МТР5 во многом отли¬ 
чается от файловой системы РПМІХ как интерфейсом пользователя, так и в плане 
реализации, что делает файловую систему 1МТР5 хорошим примером для изучения. 
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Файловая система ШТ5 является большой и сложной системой, и наша ограничен¬ 
ность в пространстве не позволяет нам обсудить все аспекты этой системы. Тем не 
менее приведенный ниже материал должен дать достаточное впечатление о ней. 

Основные понятия 

Длина имени файла в системе №ГР5 ограничена 255 символами; полная длина 
пути ограничивается 32 767 символами. Для имен файлов используется кодиров¬ 
ка Еіпісосіе, что позволяет пользователям в странах, в которых не используется 
латинский алфавит (например, в Греции, Японии, Индии, России и Израиле), пи¬ 
сать имена файлов на своем родном языке. Так, фіА,е представляет собой вполне 
допустимое имя файла. Файловая система ЫТР5 полностью поддерживает имена, 
чувствительные к регистру (таким образом,/оо отличается от Роо и РОО ). К сожа¬ 
лению, интерфейсом \Ѵіп32 АРІ не полностью поддерживается чувствительность 
к регистру для имен файлов и совсем не поддерживается для имен каталогов, по¬ 
этому это преимущество теряется при обращении к программам, обязанным ис¬ 
пользовать интерфейс \Ѵіп32 (например, для совместимости с ^іпсіо\ѵ$ 98). 

Файл в системе ЫТР5 — это не просто линейная последовательность байтов, 
как файлы в системах РАТ-32 и ПКIX. Вместо этого файл состоит из множества 
атрибутов, каждый из которых представляется в виде потока байтов. Большинство 
файлов имеет несколько коротких потоков, таких как имя файла и его 64-битовый 
идентификатор, плюс один длинный (неименованный) поток с данными. Однако 
у файла может быть и несколько длинных потоков данных. При обращении к каж¬ 
дому потоку после имени файла через двоеточие указывается имя потока, напри¬ 
мер / оо:зігеат1 . У каждого потока своя длина. Каждый поток может блокировать¬ 
ся независимо от остальных потоков. Идея нескольких потоков позаимствована 
у системы Арріе МасіпІозЬ, в которой файлы имеют по два потока, ветвь данных 
и ветвь ресурса. Эта концепция была инкорпорирована в файловую систему ИТР8, 
чтобы сервер с системой ИТР8 мог обслуживать клиенты МасіШовЬ. 

Файловые потоки могут использоваться не только для совместимости с Ма- 
сіпіовЬ. Например, программа редактирования фотографий может использовать 
неименованный поток для основного изображения, а именованный поток — для 
небольшой пиктограммы. Эта схема проще, чем традиционный способ, при кото¬ 
ром изображения помещаются в один и тот же файл, одно за другим. Другой при¬ 
мер использования потоков данных — электронная обработка текста. Эти програм¬ 
мы часто создают две версии документа, временную для использования во время 
редактирования и окончательную версию, когда пользователь закончил работу. 
Если поместить временную версию в именованный поток, а окончательную вер¬ 
сию в неименованный поток, обе версии автоматически оказываются в одном фай¬ 
ле и без какой-либо дополнительной обработки пользуются одинаковыми права¬ 
ми доступа, временными штампами и т. д. 

Максимальная длина потока составляет 2 64 байт. Чтобы получить представле¬ 
ние о том, насколько велик поток в 2 64 байт, представьте, что поток записан в дво¬ 
ичном виде, где каждый символ 0 и 1 занимает 1 мм. В этом случае листинг дли- 
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ной 2 67 мм займет 15 световых лет, выходя далеко за пределы солнечной системы, 
до Альфы Центавра и обратно. Для отслеживания местонахождения процесса 
в каждом потоке используются 64-разрядные файловые указатели. Максимальный 
же размер потока составляет около 18,4 экзабайт*. 

Вызовы функций ^іп32 АРІ для управления файлами и каталогами в первом 
приближении подобны соответствующим им двойникам в ІЖІХ, но у функций 
\Ѵіп32 АРІ больше параметров и другая модель безопасности. Процедура откры¬ 
тия файла возвращает дескриптор файла, который затем может использоваться для 
чтения этого файла или записи в файл. Для графических приложений заранее не 
определены указатели в файлах. Стандартные потоки ввода, вывода и сообщений 
об ошибках при необходимости должны открываться явно. Однако в консольном 
режиме они открываются заранее. Интерфейс \Ѵт32 также содержит ряд допол¬ 
нительных вызовов, отсутствующих в системе ІЖІХ. 

Вызовы АРІ файловой системы в ѴѴІпсІоѵѵз 2000 

Основные функции интерфейса \Ѵіп32 АРІ для работы с файлами перечислены 
в табл. 11.15. (Во второй колонке указывается ближайший эквивалент в системе 
ІЖІХ.) На самом деле их значительно больше, но приведенные в таблице данные 
дают достаточное представление об основных функциях. Рассмотрим их кратко. 
С помощью функции СгеаІеРіІ е можно создать файл и получить дескриптор к нему. 
Эту же функцию следует применять и для открытия уже существующего файла, 
так как в ^іп32 АРІ нет специальной функции РПеОреп. В таблице не приводятся 
параметры функций, потому что они слишком многочисленны. Например, функ¬ 
ция СгеаСеРПе имеет семь параметров, которые можно приближенно описать сле¬ 
дующим образом: 

1. Указатель на имя файла, который нужно создать или открыть. 

2. Флаги (биты), указывающие, может ли с этим файлом выполняться чтение, 
запись или и то и другое. 

3. Флаги, указывающие, может ли этот файл одновременно открываться не¬ 
сколькими процессами. 

4. Указатель на описатель защиты, сообщающий, кто может получать доступ 
к файлу. 

5. Флаги, сообщающие, что делать, если файл существует или, наоборот, не 
существует. 

6. Флаги, управляющие архивацией, сжатием и т. д. 

7. Дескриптор файла, чьи атрибуты должны быть клонированы для нового 
файла. 

Следующие шесть функций в табл. 11.15 довольно близко совпадают с соответ¬ 
ствующими им системными вызовами ІЖІХ. Последние две функции позволяют 
заблокировать и разблокировать часть файла, чтобы гарантировать для процесса 
исключительный доступ к этому участку файла. 


1 2 Ы байт составит 16 Эбайт ровно или 18 446 744 073 709 551 616 байт. Для байтов К означает не 1000, 
а 1024, М — не 1 000 000, а 1 048 576 и т. д. — Примеч. перво. 
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Таблица 11 , 

.15. Основные функции ѴѴіп32 АРІ для файлового ввода-вывода 

Функция 

ІШІХ 

Описание 

СгеаіеЯІе 

ореп 

Создать или открыть файл; вернуть дескриптор файла 

РеІеІеЯІе 

ипііпк 

Удалить существующий файл 

СІозеНапсІІе 

сіозе 

Закрыть файл 

ВеасІЯІе 

геас! 

Прочитать данные из файла 

ѴѴгіІеЯІе 

ѵѵгііе 

Записать данные в файл 

ЗеіЯІеРоіпІег 

Ізеек 

Установить указатель в файле в определенную позицию 

(ЗеІЯІеАПгіЬиіез зіаі 

Вернуть атрибуты файла 

ЬоскЯІе 

ІСПІІ 

Заблокировать область файла для обеспечения взаимного исключения 

ІІпІоскЯІе 

ІСПІІ 

Отменить блокировку области файла 


С помощью этих функций АРІ можно написать процедуру копирования фай¬ 
ла, аналогичную версии для системы ІШІХ в листинге 6.1. Фрагмент этой програм¬ 
мы (без какой бы то ни было проверки ошибок) приведен в листинге 11.1. Она была 
написана, чтобы сымитировать версию для системы ІШІХ. На практике копиро¬ 
вать эту программу не нужно, так как в АРІ существует функция СоруНІе, выпол¬ 
няющая приблизительно те же действия. 

Листинг 11.1. фрагмент программы для копирования файла, использующей 
функции АРІ ѴѴіпсІоѵѵз 2000 

/* Открыть файлы для ввода и вывода. */ 

іпТіапсІІ е = СгеаѣеРіІеС'сІаѣа" . СЕМЕКІС_КЕАО. 0. ШИ. 0РЕГ)_ЕХІ5ТЩС, 0. ШИ); 
оиРіапсПе = СгеаСеЕіІеГпеиГ. 0ЕШКІС_ШТЕ. 0. ШИ. СКЕАТЕфМААУЗ. 

РІЕЕ_АТТКІВІЛЕ_ШМАЕ. ШИ): 

/* Копировать файл. */ 

СІО { 

5 = КеасІРі1е(іпііапсПе. ЬиРРег, ВІІР_5І2Е. &соигтЬ. ШИ); 

іР (5 && соипѣ > 0) ЫгіТеРіІ еСоиТИапсП е. ЬиРРег. соипП & 0 СПІ. N1100): 

} и/МІе (з > 0 && соипі > 0); 

/* Закрыть файлы. */ 

СІозеНапсП еСІпИапсПе): 

С1 озеНапсП е( оиТИапсП е): 

Применяемая в операционной системе \ѴіпсІо\ѵз 2000 файловая система ІчГГРЗ 
представляет собой иерархическую файловую систему, сходную с файловой сис¬ 
темой ІШІХ. Однако в качестве разделителя между именами компонентов пути 
вместо символа / используется символ \, атавизм, унаследованный от системы 
М5-Б05. В системе ЫТРЗ также существует понятие рабочего каталога, а пути 
могут быть относительными и абсолютными. Поддерживаются жесткие и символь¬ 
ные связи. Жесткие связи реализуются, как и в системе ІШІХ, при помощи не¬ 
скольких записей в каталогах. Реализация символьных связей основана на точках 
повторного анализа (они будут обсуждаться ниже в этой главе). Поддерживаются 
сжатие, шифрование и устойчивость к сбоям. Эти свойства и их реализация также 
будут рассмотрены ниже. 

Основные функции АРI для управления каталогами приведены в табл. 11.16. Как 
и в предыдущей таблице, во втором столбце приведены аналоги из системы НИШ. 
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Таблица 11 . 16 . Основные функции \Л/іп32 АРІ для управления каталогами 

Функция 

ІШІХ 

Описание 

СгеаІеОігесІогу 

тксііг 

Создать новый каталог 

ВетоѵеОігесІогу 

гтсііг 

Удалить пустой каталог 

РіпбРігзІРІІе 

орепбіг 

Инициализация, чтобы начать чтение записей каталога 

РіпсІМехШІе 

геасісііг 

Прочитать следующую запись каталога 

МоѵеРІІе 

гепате 

Переместить файл из одного каталога в другой 

ЗеіСиггепШігесІогу 

сРісІіг 

Изменить текущий рабочий каталог 


Реализация файловой системы ѴѴіпсІоѵѵз 2000 

Система ЫТР5 представляет собой очень сложную файловую систему. Эта фай¬ 
ловая система была полностью разработана заново, и она не является попыткой 
улучшить старую файловую систему М5-005. Ниже будет рассмотрено несколь¬ 
ко ее особенностей, такие как структура, поиск файла по имени, сжатие и шифро¬ 
вание файлов. 

Структура файловой системы 

Каждый том ИТЕЗ (то есть дисковый раздел) содержит файлы, каталоги, битовые 
массивы и другие структуры данных. Каждый том организован как линейная 
последовательность блоков (кластеров по терминологии МісгозоЙ). Размер блока 
фиксирован для каждого тома и варьируется в пределах от 512 байт до 64 Кбайт, 
в зависимости от размера тома. Для большинства дисков ИТРЗ используются 
блоки размером в 4 Кбайт, как компромисс между большими блоками (для эф¬ 
фективности операций чтения/записи) и маленькими блоками (для уменьшения 
потерь дискового пространства на внутреннюю фрагментацию). Обращение к бло¬ 
кам осуществляется по их смещению от начала тома, для которого используются 
64-разрядные числа. 

Главной структурой данных в каждом томе является главная файловая табли¬ 
ца МРТ (МазГег Рііе ТаЫе), представляющая собой линейную последовательность 
записей фиксированного (1 Кбайт) размера. Каждая запись МРТ описывает один 
файл или один каталог. В ней содержатся атрибуты файла, такие как его имя и 
временные штампы, а также список дисковых адресов, указывающих на располо¬ 
жение блоков файла. Если файл очень большой, то иногда бывает необходимо ис¬ 
пользовать две и более записей главной файловой таблицы, чтобы вместить спи¬ 
сок всех блоков файла. В этом случае первая запись МРТ, называемая базовой 
записью, указывает на другие записи МРТ. Такая избыточная схема берет свое 
начало в системе СР/М, в которой каждая каталоговая запись называлась экстен¬ 
том. Какие из элементов главной файловой таблицы свободны, учитывается в би¬ 
товом массиве. 

Сама главная файловая таблица представляет собой файл и, как и любой файл, 
может располагаться в любом месте тома, тем самым устраняется проблема дефект¬ 
ных секторов на первой дорожке дискового раздела. Кроме того, этот файл может 
при необходимости расти до максимального размера в 2 48 записей. 
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Структура главной файловой таблицы показана на рис. 11.17. Каждая запись 
МРТ состоит из последовательности пар (заголовок атрибута, значение). Каждый 
атрибут начинается с заголовка, идентифицирующего этот атрибут и сообщающе¬ 
го длину значения, так как некоторые атрибуты, например имя файла или данные, 
могут иметь переменную длину. Если значение атрибута достаточно короткое, что¬ 
бы поместиться в запись МРТ, оно помещается туда. Если же это значение слиш¬ 
ком длинное, оно располагается в другом месте диска, а в запись МРТ помещается 
указатель на него. 


1 Кбайт 


16 
15 
14 
13 
12 
11 
10 
9 
8 
7 
6 
5 
4 
3 
2 
1 
0 

Рис. 11 . 17 . Главная файловая таблица КІТРЗ 

Первые 16 записей МРТ зарезервированы для файлов метаданных ЫТРЕ, как 
показано на рис. 11.17. Каждая запись описывает нормальный файл, у которого 
есть атрибуты и блоки данных, как у любого файла. У каждого такого файла есть 
имя, начинающееся с символа доллара, указывающего на то, что это файл мета¬ 
данных. Первая запись описывает сам файл МРТ. В частности, она содержит ин¬ 
формацию о расположении блоков файла МРТ, что позволяет системе найти файл 
МРТ. Очевидно, чтобы найти всю остальную информацию о файловой системе, 
у операционной системы ^іпсіоѵѵз 2000 должен быть некий способ нахождения 
первого блока файла МРТ. Номер первого блока файла МРТ содержится в загру¬ 
зочном блоке, куда он помещается при установке системы. 



Первый файл пользователя 

Зарезервировано на будущее 

Зарезервировано на будущее 

Зарезервировано на будущее 5^; 

Зарезервировано на будущее 

Расширения: квоты и т. д. 

Таблица преобразования регистра 

Описатели защиты для всех файлов 

Список дефектных блоков 

Начальный загрузчик 

Битовый массив использованных блоков 

Корневой каталог 

Определения атрибутов 

Файл тома 

Журнал для восстановления 

Зеркальная копия МРТ 

Главная файловая таблица 


Файлы метаданных 




916 


Глава 11. Рассмотрение конкретных случаев: ѴѴіпбоѵѵз 2000 


Запись 1 представляет собой дубликат первой части файла МРТ. Эта инфор¬ 
мация является настолько ценной, что наличие второй копии может быть необхо¬ 
димо на случай, если один из первых блоков главной файловой таблицы вдруг ста¬ 
нет дефектным. Запись 2 представляет собой журнал. Когда в файловой системе 
производятся структурные изменения, такие как добавление нового каталога или 
удаление существующего каталога, информация о предстоящей операции реги¬ 
стрируется в журнале. Таким образом, увеличивается вероятность корректного 
восстановления файловой системы в случае сбоя во время выполнения операции. 
Изменения атрибутов файлов также регистрируются здесь. В этом журнале не 
регистрируются только изменения данных пользователя. В записи 3 содержится 
информация о томе, например его размер, метка и версия. 

Как уже сообщалось, каждая запись МЕТ содержит последовательность пар 
(заголовок атрибута, значение). Файл $АПгБе/ является тем местом, в котором 
определяются атрибуты. Информация об этом файле хранится в записи 4 табли¬ 
цы МРТ. В следующей записи содержатся данные о корневом каталоге, который 
сам представляет собой файл и может произвольно увеличиваться в размерах. 
Он описывается записью 5 главной файловой таблицы. 

Свободное место на диске учитывается с помощью битового массива. Битовый 
массив сам является файлом, и его атрибуты и дисковые адреса хранятся в запи¬ 
си 6 таблицы МРТ. Следующая запись таблицы МРТ указывает на файл начальной 
загрузки. Запись 8 используется для того, чтобы связать вместе все дефектные 
блоки и гарантировать, что они никогда не встретятся в файлах. Запись 5> содер¬ 
жит информацию о защите. Запись 10 используется для преобразования регистра. 
Для символов латинского алфавита от А до 2 преобразование регистра не представ¬ 
ляет проблем (по крайней мере для тех, кто говорит на языке с латиницей). Для дру¬ 
гих языков, таких как греческий, армянский или грузинский, этот вопрос не столь 
очевиден, как для использующих латынь, поэтому этот файл содержит необходи¬ 
мые инструкции. Наконец, запись 11 представляет собой каталог, содержащий раз¬ 
личные файлы для дисковых квот, идентификаторов объектов, точек повторного 
анализа и т. д. Последние четыре записи МРТ зарезервированы на будущее. 

Каждая запись МРТ состоит из заголовка записи, за которым следует после¬ 
довательность пар (заголовок атрибута, значение). Заголовок записи содержит 
магическое число, используемое для проверки действительности записи; поряд¬ 
ковый номер, обновляемый каждый раз, когда запись используется для нового 
файла; счетчик обращений к файлу; действительное количество байт, использу¬ 
емых в записи; идентификатор (индекс, порядковый номер) базовой записи 
(используемый только для записей расширения), а также другие различные поля. 
Следом за заголовком записи располагается заголовок первого атрибута, за кото¬ 
рым идет значение первого атрибута, потом заголовок второго атрибута, значение 
второго атрибута и т. д. 

В файловой системе РГГР5 определено 13 атрибутов, которые могут появ¬ 
ляться в записях МРТ. Они перечислены в табл. 11.17. Все записи таблицы МРТ 
состоят из последовательности заголовков атрибутов, каждый из которых иден¬ 
тифицирует следующий за ним атрибут, а также содержит длину и расположе¬ 
ние поля значения вместе с разнообразными флагами и прочей информацией. 
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Как правило, значения атрибутов располагаются непосредственно за заголовками, 
но если длина значения слишком велика, чтобы поместиться в запись таблицы 
МЕТ, она может быть помещена в отдельный блок диска. Такой атрибут называ¬ 
ется нерезидентным атрибутом. Например, таким атрибутом является атрибут 
данных. Некоторые атрибуты, такие как атрибуты имени, могут повторяться, 
но все атрибуты должны располагаться в записи МЕТ в фиксированном поряд¬ 
ке. Длина заголовков резидентных атрибутов 24 байт, заголовки для нерезидент¬ 
ных атрибутов длиннее, так как они содержат информацию о месте расположения 
атрибута. 


Таблица 11.17. Атрибуты, используемые в записях МЕТ 


Атрибут 


Описание 


Стандартная информация 
Имя файла 

Описатель защиты 

Список атрибутов 
Идентификатор объекта 

Точка повторного анализа 
Название тома 
Информация о томе 
Корневой индекс 
Размещение индекса 
Битовый массив 

Поток данных утилиты регистрации 
Данные 


Флаговые биты, временные штампы и т. д. 

Имя файла в кодировке ІІпісосІе; может быть также 
повторено для имени МЗ-йОЗ 

Устарел. Теперь информация о защите располагается 
в атрибуте $ЕхІепсІ$8есиге 
Расположение дополнительных записей МРТ 
64-разрядный идентификатор файла, уникальный 
для данного тома 

Используется для монтирования и символьных ссылок 
Название тома (используется только в $ѴоІите) 
Версия тома (используется только в ЗѴоІите) 
Используется для каталогов 
Используется для очень больших каталогов 
Используется для очень больших каталогов 
Управляет регистрацией в файле $І_одРіІе 
Поточные данные; может повторяться 


Стандартное информационное поле содержит сведения о владельце файла, ин¬ 
формацию о защите, временные штампы, необходимые для стандарта Р05ІХ, счет¬ 
чик жестких связей, бит «только чтение», архивный бит и г. д. Эго поле имеет фик¬ 
сированную длину, и оно всегда присутствует. Имя файла хранится в кодировке 
Ипісосіе в поле переменной длины. Чтобы старые 16-разрядные программы могли 
работать с файлами, файлы также могут содержать имена формата М5-Б05 8+3. 
Если имя файла удовлетворяет правилам именования файлов в М5-Э05, второе 
имя формата М5-Э05 не используется. 

В операционной системе N4 4.0 информация о защите файла могла содержать¬ 
ся в атрибуте файла, но в ^іпсіо\ѵз 2000 эти данные хранятся в отдельном файле, 
что позволяет нескольким файлам совместно пользоваться общими описателями 
защиты. Список атрибутов нужен на случай, если атрибуты не помещаются в за¬ 
пись МЕТ. Каждая запись в списке содержит 48-разрядный индекс в таблице МЕТ, 
указывающий на запись расширения, а также 16-разрядный порядковый номер, 
позволяющий проверить соответствие записи расширения и базовой записи. 

Атрибут идентификатор объекта задает файлу уникальный номер. Иногда он 
используется внутри системы. Точка повторного анализа велит процедуре, анали- 
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зирующей имя файла, выполнить специальные действия. Этот механизм применя¬ 
ется для монтирования устройств и символьных ссылок. Два следующих атрибу¬ 
та используются только для идентификации тома. Еще три атрибута используют¬ 
ся для реализации каталогов. Небольшие каталоги представляют собой простые 
списки файлов, но большие каталоги реализуются в виде деревьев В+. Поток дан¬ 
ных утилиты регистрации используется шифрующей файловой системой. 

Наконец, мы добрались до атрибута, которого все так ждали: до атрибута дан¬ 
ных. Имя потока данных, если оно присутствует, располагается в этом заголов¬ 
ке атрибута. Следом за этим заголовком располагается либо список дисковых ад¬ 
ресов, определяющий положение файла на диске, либо, для файлов длиной всего 
в несколько сотен байтов (а таких файлов довольно много), сам файл. Метод по¬ 
мещения самого содержимого файла в запись МРТ называется непосредственным 
файлом [241]. 

Конечно, в большинстве случаев все данные файла не помещаются в запись 
МЕТ, поэтому этот атрибут, как правило, является нерезидентным. Рассмотрим 
теперь, как в файловой системе ИТР5 отслеживается расположение нерезидент¬ 
ных атрибутов, в частности данных. 

Для увеличения эффективности дисковые блоки файлам назначаются по воз¬ 
можности в виде серий последовательных блоков (сегментов файла). Например, 
если первый логический блок файла помещается в блоке 20 на диске, тогда систе¬ 
ма будет стараться выделить для второго блока этого файла блок 21, для третье¬ 
го — блок 22 и т. д. Один из способов выделения файлам таких серий блоков за¬ 
ключается в том, чтобы предоставлять файлам сразу по несколько блоков. 

Блоки в файле описываются последовательностью записей, каждая из которых 
описывает последовательность логически непрерывных блоков. Непрерывный 
файл описывается всего одной записью. К этой категории относятся файлы, за¬ 
писываемые за одну операцию от начала до конца. Файл с одной «дыркой» (на¬ 
пример файл, для которого определены только блоки с 0 по 49 и с 60 по 79), будет 
описываться двумя записями. Такой файл может быть создан, если сначала запи¬ 
сать в него первые 50 блоков, затем переместить указатель в файле на логический 
блок 60 и записать еще 20 блоков. Когда из такого файла читается «дырка», все 
отсутствующие байты оказываются нулями. 

Каждая запись начинается с заголовка, определяющего смещение первого бло¬ 
ка в файле. Затем располагается смещение первого блока, не покрываемого пер¬ 
вой записью. Для приведенного выше примера у первой записи будет заголовок 
(0,50), а сама запись будет содержать дисковые адреса для первых 50 блоков фай¬ 
ла. Вторая запись будет иметь заголовок (60,80) и содержать дисковые адреса для 
следующих 20 блоков файла. 

Следом за каждым заголовком располагаются пары, в которых содержатся 
дисковые адреса и длины серий блоков. Эти дисковые адреса представляют собой 
смещение блока от начала дискового раздела. Длина серии — это количество бло¬ 
ков в серии. В записи серии может содержаться любое необходимое количество 
пар. Использование этой схемы для 9-блочного файла, состоящего из трех сегмен¬ 
тов, проиллюстрировано на рис. 11.18. 
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Рис. 11.18. Запись МРТ для 9-блочного файла, состоящего из трех сегментов 


На этом рисунке показана запись МРТ для короткого файла («короткий файл» 
здесь означает, что вся информация о блоках файла помещается в одну запись 
МРТ). Файл состоит из трех серий последовательных блоков диска. Первая серия 
блоков располагается в блоках диска с 20 по 23, вторая — в 64 и 65, и третья — с 80 
по 82. Каждая серия записывается в записи МРТ в виде пары (дисковый адрес, 
количество блоков). Число таких серий зависит от того, насколько удачно проце¬ 
дура предоставления дискового пространства сумела найти место для хранения 
файла при его создании. Для файла, состоящего из п блоков, количество серий 
может быть любым от 1 до п. 

Здесь следует сказать несколько слов. Во-первых, данный способ представле¬ 
ния информации о расположении блоков файла на диске не накладывает никаких 
дополнительных ограничений на размер файла. При отсутствии сжатия адреса для 
каждой пары требуется два 64-разрядных числа, что составляет 16 байт на пару. 
Однако одна пара может указывать на миллион последовательных блоков. На¬ 
пример, 20-мегабайтный файл, состоящий из 20 сегментов по 1 млн килобайтных 
блоков каждый, легко может быть описан всего одной записью МРТ, тогда как 
60-килобайтный файл, состоящий из 60 изолированных блоков, не может. 

Во-вторых, хотя при использовании простого метода представления пары 
требуется 2x8 байт, эти 16 байт могут быть сжаты до меньшего размера. Многие 
дисковые адреса содержат большое количество нулей в старших байтах. Нули 
могут быть опущены. В этом случае в заголовке данных будет содержаться инфор¬ 
мация о том, сколько байтов пропущено, то есть сколько байтов фактически ис¬ 
пользуется для дискового адреса. Также используются и другие методы сжатия 
данных. На практике пары часто занимают всего 4 байт. 

Наш первый пример был довольно прост: вся информация о файле помеща¬ 
лась в одну запись МРТ. Что произойдет, если файл окажется настолько велик 
или будет настолько фрагментирован, что информация о блоках не поместится 
в одну запись МРТ? Ответ прост: нужно использовать две или более записей МРТ. 
На рис. 11.19 показан файл, базовая запись которого располагается в записи 102 
таблицы МРТ. Этот файл состоит из слишком большого количества сегментов, 
чтобы информация о них могла поместиться в одну запись МРТ, поэтому для 
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этого файла вычисляется необходимое ему число записей расширения — напри¬ 
мер, две, — и их индексы помещаются в базовую запись. Оставшаяся часть записи 
используется для адресов первых к сегментов файла. 



Вторая запись расширения 


Первая запись расширения 


Заголовок записи 


Рис. 11.19. Файл, которому требуется три записи МРТ для хранения данных 
обо всех своих сегментах 


Обратите внимание, что схема на рис. 11.19 содержит некоторую избыточную 
информацию. Теоретически необходимости указывать конец последовательности 
сегментов нет, так как эта информация может быть вычислена по сегментным па¬ 
рам. Причина, по которой эта информация дублируется, заключается в повыше¬ 
нии эффективности поиска блока файла. Чтобы найти блок по смещению в фай¬ 
ле, нужно всего лишь изучить заголовки записей, а не сами сегментные пары. 

Когда все пространство в записи 102 использовано, сегментные пары помещают¬ 
ся в запись 105. В эту запись помещается столько пар, сколько туда влезет. Когда 
и эта запись оказывается заполненной, остальные пары помещаются в запись 108. 
Таким образом, для хранения больших фрагментированных файлов может быть 
использовано несколько записей таблицы МРТ. 

Проблема может возникнуть, если потребуется так много записей МРТ, что 
в базовой записи не поместятся все индексы МРТ. Эта проблема решается следу¬ 
ющим образом: список записей МРТ делается нерезидентным (то есть хранится 
отдельно на диске, а не в базовой записи МРТ). В этом случае его размер уже 
ничем не ограничен. 

Запись МРТ для небольшого каталога показана на рис. 11.20. Запись МРТ со¬ 
держит несколько каталоговых записей, каждая из которых описывает файл или 
каталог. Фиксированная часть содержит индекс записи МРТ файла, длину имени 
файла, а также другие разнообразные поля и флаги. Поиск файла в каталоге по 
имени состоит в последовательном переборе всех имен файлов. 
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Рис. 11.20. Запись МРТ для небольшого каталога 
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Для больших каталогов используется другой формат. Вместо того чтобы линей¬ 
но перечислять файлы, используется дерево В+, обеспечивающее поиск в алфа¬ 
витном порядке и упрощающее добавление в каталог новых имен в соответству¬ 
ющие места. 

Поиск файла по имени 

Теперь мы обладаем достаточной информацией, чтобы понять, как осуществляет¬ 
ся поиск файла по имени. Когда пользовательская программа пытается открыть 
файл, она обычно обращается к библиотечной процедуре вроде следующей: 

СгеаіеРі1е("С:\тагіа\кеЬ.Щш" . ...) 

Этот вызов попадает в совместно используемую библиотеку уровня пользова¬ 
теля кете132.(111, где \?? помещается перед именем файла, в результате чего полу¬ 
чается строка 

\??\С:\шагіа\кеЬ.РіІш 

Это имя пути передается системному вызову НѢРПеСгеаѣе в качестве параметра. 
Затем операционная система начинает поиск в корне пространства имен менед¬ 
жера объектов (см. табл. 11.7). После этого она ищет и находит С: в каталоге \??. 
Этот файл представляет собой символьную ссылку на другую часть пространства 
имен менеджера объектов, на каталог \Оеѵісе. Ссылка, как правило, указывает на 
объект с именем вроде \Оеѵісе\НагсІ(1ізкѴоІите1 . Этот объект соответствует пер¬ 
вому разделу первого жесткого диска. По объекту можно определить, какую таб¬ 
лицу МРТ, располагающуюся на этом дисковом разделе, следует использовать. 
Этапы поиска файла показаны на рис. 11.21. 


МРТ для тома 1 


5. Возврат манипулятора 
вызывающему процессу 



раздел диска 3. Поиск имени пути 

Рис. 11.21. Этапы поиска файла С:\тагіа\ѵѵеЬ.Мт 


Анализ имени файла продолжается теперь в корневом каталоге дискового раз¬ 
дела, блоки которого можно найти в записи 5 таблицы МРТ (см. рис. 11.17). Затем 
в корневом каталоге ищется строка «тагіа», в результате чего процесс получает 
индекс в таблице МРТ для каталога тагіа. Затем в каталоге тагіа ищется строка 
«ѵ/еЬ.Ьіт». Если поиск завершается успешно, то результатом его является новый 
объект, созданный менеджером объектов. Этот объект, не имеющий имени, содер- 
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жит индекс в таблице МРТ для найденного файла. Вызывающему процессу возвра¬ 
щается дескриптор этого объекта. При последующих вызовах КеасіРіІе в качестве 
входного параметра используется дескриптор объекта, что позволяет менеджеру 
объектов найти индекс, а затем и содержимое записи МРТ для этого файла. Если 
этот же файл откроет второй поток, ему будет предоставлен дескриптор нового 
объекта файла. 

Помимо обычных файлов и каталогов, файловая система РІТРЗ поддерживает 
жесткие связи, подобные используемым в ІЖІХ, а также символьные ссылки при 
помощи механизма, называемого точками повторного анализа. Файл или каталог 
может быть помечен как точка повторного анализа, и с ним может быть ассоци¬ 
ирован блок данных. Когда во время анализа имени файла встречается такой файл 
или каталог, срабатывает обработка исключения и интерпретируется блок данных. 
Блок может выполнять различные действия, включая переадресацию поиска, ссы¬ 
лаясь на другую часть дерева каталогов или даже на другой дисковый раздел. Этот 
механизм используется для поддержки как символьных ссылок, так и монтиров¬ 
ки файловых систем. 

Сжатие файлов 

Файловая система РІТРЗ поддерживает прозрачное сжатие файлов. Файл может 
быть создан в сжатом режиме. Это означает, что файловая система РІТРЗ будет ав¬ 
томатически пытаться сжать блоки этого файла при записи их на диск и автомати¬ 
чески распаковывать их при чтении. Процессы, читающие этот файл или пишу¬ 
щие в него, не будут даже догадываться о том, что при этом происходит компрессия 
или декомпрессия данных. 

Сжатие данных файла происходит следующим образом. Когда файловая сис¬ 
тема 1ѴТР5 записывает на диск файл, помеченный для сжатия, она изучает первые 
16 (логических) блоков файла, независимо от того, сколько сегментов на диске они 
занимают. Затем к этим блокам применяется алгоритм сжатия. Если полученные 
на выходе блоки могут поместиться в 15 или менее блоков, то сжатые данные за¬ 
писываются на диск, предпочтительно в виде одного сегмента. Если получить вы¬ 
игрыш хотя бы в один блок не удается, то данные 16 блоков так и записываются в 
несжатом виде. Затем весь алгоритм повторяется для следующих 16 блоков и т. д. 

На рис. 11.22, а показан файл, в котором первые 16 блоков успешно сжаты в 
8 блоков, следующие 16 блоков не могутбыть сжаты, наконец, последние 16 блоков 
также успешно сжаты на 50 %. Эти три части файла записаны в виде трех сегментов, 
информация о которых хранится в записи МРТ. «Пропущенные» блоки обозна¬ 
чаются в записи МРТ как сегменты с нулевым дисковым адресом (рис. 11.22, б). 
Здесь за заголовком (0,48) следует пять пар, две для первого (сжатого) сегмента, одна 
для несжатого сегмента и две для последнего (сжатого) сегмента. 

При чтении этого файла система РІТРЗ должна знать, какие из сегментов файла 
сжаты, а какие нет. Она видит это по дисковым адресам. Дисковый адрес 0 указы¬ 
вает на то, что предыдущий сегмент сжат. Дисковый блок 0 не может использо¬ 
ваться для хранения данных во избежание неоднозначности. Поскольку в этом 
блоке содержится загрузочный сектор, использование этого блока для хранения 
данных все равно невозможно. 
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Рис. 11.22. Пример 48-блочного файла, сжатого до 32 блоков (а); 
запись МП" после сжатия файла (б) 

Произвольный доступ к сжатому файлу возможен, но не совсем прост. Пред¬ 
положим, процесс обращается к блоку 35 файла, показанного на рис. 11.22. Как 
файловой системе ЫТР5 найти блок 35 в сжатом файле? Ответ состоит в том, что 
для этого сначала потребуется прочитать и распаковать весь сегмент файла. После 
этого система может определить, где находится блок 35, и передать его читающему 
процессу. Сжатие файла частями именно по 16 блоков явилось компромиссом. 
Если бы файл сжимался меньшими порциями, эффективность сжатия снизилась 
бы. Выбор больших размеров сжимаемых фрагментов привел бы к замедлению 
произвольного доступа к блокам. 

Шифрование файлов 

Сегодня компьютеры используются для хранения самых разнообразных конфи¬ 
денциальных данных, включая планы слияния корпораций, налоговую информа¬ 
цию и любовную переписку. Владельцы подобных данных, как правило, не жела¬ 
ют, чтобы она попала в посторонние руки. Информация может оказаться потеряна, 
например, при потере или краже переносного компьютера. Настольный компью¬ 
тер можно загрузить с гибкого диска с системой М5-И05, чтобы обойти систему 
безопасности ^іп<іо\ѵ5 2000. Наконец, жесткий диск можно просто вынуть из 
одного компьютера и установить на другой компьютер. Очень опасной может 
оказаться даже прогулка в туалет, если компьютер будет оставлен без присмотра 
во включенном состоянии. 

В операционной системе ^іпс1о\ѵ5 2000 эти проблемы решаются при помощи 
возможности шифрования файлов. В результате применения шифрования, даже 
если компьютер будет украден или перезагружен в системе МВ-БОЗ, файлы оста¬ 
нутся нечитаемыми. Чтобы использовать шифрование в операционной системе 
\ѴіпсІо\ѵ5 2000, нужно пометить каталог как зашифрованный, в результате чего 
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будут зашифрованы все файлы в этом каталоге, а все новые файлы, перемещен¬ 
ные в этот каталог или созданные в нем, также будут зашифрованы. Само шифро¬ 
вание и дешифрование выполняется не файловой системой ЫТР5, а специальным 
драйвером ЕР8 (Епсгурііп§ Рііе Зузіет — шифрующая файловая система), разме¬ 
щающимся между РІТР5 и пользовательским процессом. Таким образом, приклад¬ 
ная программа не знает о шифровании, а сама файловая система РГТР5 только 
частично вовлечена в этот процесс. 

Чтобы понять, как работает система шифрования файлов, необходимо пони¬ 
мать, как работает современная система шифрования. Для этого в разделе «Осно¬ 
вы криптографии» главы 9 был дан краткий обзор данной темы. Читатели, не зна¬ 
комые с основами криптографии, должны сначала прочитать этот раздел. 

Познакомимся теперь с тем, как шифруются файлы в операционной системе 
\Ѵіпс1о\Ѵ5 2000. Когда пользователь сообщает системе, что хочет зашифровать оп¬ 
ределенный файл, формируется случайный 128-разрядный ключ. Ключ использу¬ 
ется для поблочного шифрования файла с помощью симметричного алгоритма, 
параметром в котором используется этот ключ. Каждый новый шифруемый файл 
получает новый случайный 128-разрядный ключ, так что никакие два файла не 
используют один и тот же ключ шифрования, что увеличивает защиту данных 
в случае, если какой-либо из ключей окажется скомпрометированным. Приме¬ 
няемый в настоящий момент алгоритм шифрования представляет собой вариант 
стандартного алгоритма ОЕ8 (Паіа Епсгурііоп Зіапсіагб — стандарт шифрования 
данных), но архитектура ЕГ5 поддерживает добавление новых алгоритмов в буду¬ 
щем. Независимое шифрование каждого блока файла необходимо для сохранения 
возможности произвольного доступа к блокам файла. 

Чтобы файл мог быть впоследствии расшифрован, ключ файла должен где-то 
храниться. Если бы ключ хранился на диске в открытом виде, тогда злоумышлен¬ 
ник, укравший файлы, мог бы легко найти его и воспользоваться им для расшиф¬ 
ровки украденных файлов. В этом случае сама идея шифрования файлов оказа¬ 
лась бы бессмысленной. Поэтому ключи файлов сами должны храниться на диске 
в зашифрованном виде. Для этого используется шифрование с открытым ключом. 

После того как файл зашифрован, система с помощью информации в систем¬ 
ном реестре ищет расположение открытого ключа пользователя. Открытый ключ 
можно без каких-либо опасений хранить прямо в реестре, так как по открытому 
ключу невозможно определить закрытый ключ, необходимый для расшифровки 
файлов. Затем случайный 128-разрядный ключ файла шифруется открытым клю¬ 
чом, а результат сохраняется на диске вместе с файлом, как показано на рис. 11.23. 

Чтобы расшифровать файл, с диска считывается зашифрованный случайный 
128-разрядный ключ файла. Однако для его расшифрован необходим закры¬ 
тый ключ. В идеале этот ключ должен храниться на смарт-карте, вне компьютера, 
и вставляться в считывающее устройство только тогда, когда требуется рас¬ 
шифровать файл. Хотя операционная система \\Чпс1о\ѵ5 2000 поддерживает смарт- / 
карты, она не позволяет хранить на них закрытые ключи. 

Вместо этого, когда пользователь в первый раз зашифровывает файл с помо¬ 
щью системы ЕГ5, операционная система \Ѵіп<іо\ѵ5 2000 формирует пару ключей 
(закрытый ключ, открытый ключ) и сохраняет закрытый ключ, зашифрованный 
при помощи симметричного алгоритма шифрования, на диске. Ключ для этого 
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симметричного алгоритма формируется либо из пароля пользователя для регист¬ 
рации в системе, либо из ключа, хранящегося на смарт-карте, если регистрация при 
помощи смарт-карты разрешена. Таким образом, система ЕГ5 может расшифро¬ 
вать закрытый ключ во время регистрации пользователя в системе и хранить его 
в своем виртуальном адресном пространстве во время работы, чтобы иметь воз¬ 
можность расшифровывать 128-разрядные ключи файлов без дополнительного об¬ 
ращения к диску. Когда компьютер выключается, закрытый ключ стирается из 
виртуального адресного пространства системы ЕГ5, так что никто, даже украв 
компьютер, не получит доступа к закрытому ключу. 

Ключ К получается в результате 
применения закрытого ключа 
Случайный пользователя к ключу, 

128-разрядный хранящемуся на диске 

ключ К к 



Сложности возникают тогда, когда нескольким пользователям требуется дос¬ 
туп к одному и тому же зашифрованному файлу. В настоящий момент совместное 
использование зашифрованных файлов несколькими пользователями не поддер¬ 
живается. Однако в будущем архитектура ЕГ5 может поддержать совместное ис¬ 
пользование, если ключ шифрования файла будет зашифровываться несколько 
раз, отдельно для каждого авторизованного пользователя, его закрытым ключом. 
Все зашифрованные версии ключа могут добавляться к файлу. 

Потенциальная потребность в совместном использовании зашифрованных 
файлов является одной из причин, по которой применяется такая двухуровневая 
система ключей. Если бы все файлы зашифровывались ключами владельцев фай¬ 
лов, то совместное использование зашифрованных файлов было бы невозможным. 
Эта проблема может быть решена, если для зашифровки каждого файла использо¬ 
вать отдельный ключ. 

Схема с использованием случайных ключей для шифрования файлов, но с шиф¬ 
рованием самих ключей при помощи симметричного алгоритма шифрования не 
будет работать. Проблема в том, что наличие симметричного ключа, хранящегося 
на диске в открытом виде, разрушит всю систему защиты — сформировать ключ 
дешифрации по ключу шифрования слишком легко. Таким образом, медленное 
шифрование с открытым ключом требуется для шифрования ключей файлов. 






926 


Глава 11. Рассмотрение конкретных случаев: ѴѴіпсІоѵѵз 2000 


Поскольку ключи шифрования все равно являются открытыми, хранение их в от¬ 
крытом виде не представляет опасности. 

Вторая причина использования двухуровневой системы ключей заключается в 
производительности. Использование криптографии с открытым ключом для шиф¬ 
рования файлов было бы слишком медленным. Для повышения эффективности 
шифрование с открытым ключом применяется лишь для зашифровки коротких 
128-разрядных ключей файлов, тогда как для шифрования самих файлов исполь¬ 
зуется симметричный алгоритм. 


Безопасность в ѴѴіпсІоѵѵз 2000 

Познакомившись с шифрованием в файловой системе, рассмотрим теперь систе¬ 
му безопасности в \Уіпс1о\ѵ5 2000 в целом. Операционная система ]ч[Т была раз¬ 
работана так, чтобы соответствовать уровню С2 требований безопасности Мини¬ 
стерства обороны США (ЭоЭ 5200.28-5ТО), Оранжевой книги, обсуждавшейся 
в главе 9. Этот стандарт требует наличия у операционных систем определенных 
свойств, позволяющих относить данные системы к достаточно надежным для 
выполнения военных задач определенного рода. Хотя при разработке операци¬ 
онной системы \Ѵіпс1о\ѵ5 2000 не ставилось особой цели соответствия требовани¬ 
ям уровня С2, она унаследовала множество свойств безопасности от МТ, включая 
следующие: 

1. Безопасная регистрация в системе с мерами предосторожности против по¬ 
пыток применения фальшивой программы регистрации. 

2. Дискреционное управление доступом. 

3. Управление привилегированным доступом. 

4. Защита адресного пространства для каждого процесса. 

5. Обнуление страниц перед выделением их процессу. 

6. Аудит безопасности. 

Рассмотрим кратко эти аспекты (ни один из них не встречается в \Ѵіпс1о\ѵ5 98). 

Безопасная регистрация означает, что системный администратор может потре¬ 
бовать ото всех пользователей наличия пароля для входа в систему. Программа, 
имитирующая регистрацию в системе, использовалась ранее на некоторых систе¬ 
мах злоумышленниками с целью выведать пароль пользователя. Такая программа 
запускалась в надежде, что пользователь сядет за компьютер и введет свое имя и 
пароль. Имя и пароль записывались на диск, после чего пользователю сообщалось, 
что в регистрации ему отказано. В операционной системе \Уіпс1о\ѵ5 2000 подоб¬ 
ный обман пользователя невозможен, так как пользователь для входа в систему 
должен нажать комбинацию клавиш СТКІ_+АІ_Т+0ЕІ_. Эта комбинация клавиш всегда 
перехватывается драйвером клавиатуры, который вызывает при этом настоящую 
программу регистрации. Пользовательский процесс не может сам перехватить эту 
комбинацию клавиш или отменить ее обработку драйвером. 

Дискреционное управление доступом позволяет владельцу файла или другого 
объекта указать, кто может пользоваться объектом и каким образом. Средства 
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управления привилегированным доступом позволяют системному администрато¬ 
ру (суперпользователю) получать доступ к объекту, несмотря на установленные 
его владельцем разрешения доступа. Под защитой адресного пространства имеется 
в виду лишь то, что у каждого процесса есть собственное защищенное виртуаль¬ 
ное адресное пространство, недоступное для любого неавторизованного процесса. 
Следующий пункт означает, что при увеличении стека выделяемые для него стра¬ 
ницы заранее обнуляются, так что процесс не может обнаружить в них информа¬ 
ции, помещенной предыдущим владельцем страницы памяти (страницы подаются 
процессам из списка обнуленных страниц, показанного на рис. 11.14). Наконец, 
аудит безопасности следует понимать как регистрацию системой в журнале опре¬ 
деленных событий, относящихся к безопасности. Впоследствии этот журнал может 
просматривать системный администратор. 

В следующем разделе будут описаны основные понятия безопасности опера¬ 
ционной системы \Ѵішіо\Ѵ5 2000. После этого мы обсудим системные вызовы 
безопасности. Наконец, мы рассмотрим вопросы реализации системы безопаснос¬ 
ти в \Ѵтс1о\ѵ5 2000. 

Основные понятия 

У каждого пользователя (и группы) операционной системы \Ѵтс1о\У5 2000 есть 
идентификатор безопасности 5ГО (Зесигііу Шепііііег), по которому операцион¬ 
ная система отличает его от других пользователей. Идентификаторы безопаснос¬ 
ти представляют собой двоичные числа с коротким заголовком, за которым следу¬ 
ет длинный случайный компонент. Каждый 5ГО должен быть уникален в пределах 
всей планеты. Когда пользователь запускает процесс, этот процесс и его потоки 
работают под идентификатором пользователя. Большая часть системы безопасно¬ 
сти спроектирована так, чтобы гарантировать предоставление доступа к каждому 
объекту только потокам с авторизованными идентификаторами безопасности. 

У каждого процесса есть маркер доступа, в котором указывается 5ГО и другие 
свойства. Как правило, он назначается при регистрации в системе процедурой 
тіпіо^оп. Структура маркера доступа показана на рис. 11.24. Чтобы получить эту 
информацию, процесс должен вызвать функцию СеіТокепІп/огтайоп, так как она 
может измениться со временем. Заголовок маркера содержит некоторую админи¬ 
стративную информацию. По значению поля срока действия можно определить, 
когда маркер перестанет быть действйтельным, но в настоящее время это поле не 
используется. Поле Сгоирз (группы) указывает группы, к которым принадлежит 
процесс. Это поле необходимо для соответствия требованиям стандарта РОЗІХ. 
Поле Бе/аик ИАСЬ (ОАСЬ по умолчанию, Оізсгеііопагу Ассезз Сопігоі Бізі — 
список разграничительного контроля доступа) представляет собой список управ¬ 
ления доступом, назначаемый объектам, созданным процессом, если не опреде¬ 
лены другие списки АСЬ. Идентификатор безопасности пользователя указывает 
пользователя, владеющего процессом. Ограниченные идентификаторы 5Ш по¬ 
зволяют ненадежным процессам принимать участие в заданиях вместе с надеж¬ 
ными процессами, но с меньшими полномочиями и меньшими возможностями 
причинения ущерба. 
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Рис. 11.24. Структура маркера доступа 


Наконец, перечисленные в маркере привилегии (если они перечислены) дают 
процессу особые полномочия, такие как право выключать компьютер или полу¬ 
чать доступ к файлам, к которым в противном случае в этом доступе процессу было 
бы отказано. Привилегии позволяют разбить полномочия системного админист¬ 
ратора на отдельные права, которые могут предоставляться процессам по отдель¬ 
ности. Таким образом, пользователю может быть предоставлена часть полномо¬ 
чий суперпользователя, но не все его полномочия. Итак, маркер доступа содержит 
информацию о том, кто владеет процессом и какие умолчания и полномочия ассо¬ 
циированы с ним. 

Когда пользователь регистрируется в системе, процесс тпІо§оп назначает мар¬ 
кер доступа начальному процессу. Последующие процессы, как правило, наследу¬ 
ют этот маркер. Маркер доступа процесса изначально применяется ко всем пото¬ 
кам процесса. Однако поток во время исполнения может получить другой маркер 
доступа. В этом случае маркер доступа потока перекрывает маркер доступа про¬ 
цесса. В частности, клиентский поток может передать свой маркер доступа сервер¬ 
ному потоку, чтобы сервер мог получить доступ к защищенным файлам и другим 
объектам клиента. Такой механизм называется перевоплощением. 

Другим основным понятием является дескриптор защиты. У каждого объекта 
есть ассоциированный с ним дескриптор защиты, содержащий список пользова¬ 
телей и групп, имеющих доступ к данному объекту. Дескриптор защиты состоит 
из заголовка, за которым следует список Б АСЬ с одним или несколькими элемен¬ 
тами АСЕ (Ассезз Сопігоі Епігу — элемент списка контроля доступа АСЬ). Два 
основных типа элементов списка — это разрешение и запрет доступа. Разрешаю¬ 
щий элемент содержит 5ГО пользователя или группы и битовый массив, опре¬ 
деляющий набор операций, которые процессы с данным идентификатором 5Ш 
могут выполнять с определенным объектом. Запрещающий элемент работает ана¬ 
логично, но совпадение идентификаторов означает, что обращающийся процесс не 
может выполнять перечисленные операции. Например, у Иды есть файл, дескрип¬ 
тор защиты которого указывает, что у всех пользователей есть доступ для чтения 
этого файла, Элвису запрещен всякий доступ, а у самой Иды есть все виды досту¬ 
па. Этот простой пример показан на рис. 11.25. Идентификатор защиты Еѵегуопе 
(все) соответствует множеству всех пользователей, но его действие может пере¬ 
крываться любым элементом списка, в котором явно указано нечто иное. 

Кроме списка ИАСЬ у дескриптора защиты есть также список 8АСЬ (Зузіет 
Ассезз Сопігоі Ілзі — системный список контроля доступа), который похож на 
ИАСЬ, только вместо пользователей и групп, имеющих доступ к объекту, в нем 
перечисляются операции с этим объектом, регистрируемые в специальном журна¬ 
ле. На рис. 11.25 все действия, которые Мэрилин выполнит с этим файлом, будут 
регистрироваться в журнале. В операционной системе \Ѵіпсіо\ѵз 2000 также пре¬ 
доставляются дополнительные возможности аудита для регистрации доступа к 
объектам. 
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Рис. 11.25. Пример дескриптора защиты для файла 


Вызовы АРІ защиты 

В основе большей части механизмов управления доступом в \Уіпс1о\ѵ5 2000 лежат 
дескрипторы защиты. Как правило, когда процесс создает объект, он передает функ¬ 
ции СгеаІеРгосезз, СгеаІеРіІе или другой функции в качестве одного из парамет¬ 
ров дескриптор защиты. Этот дескриптор защиты затем становится дескриптором 
защиты, присоединенным к объекту (см. рис. 11.25). Если при создании объекта 
не предоставляется дескриптора защиты, используется дескриптор защиты вызы¬ 
вающего процесса по умолчанию (см. рис. 11.24). 

Для управления дескрипторами защиты существует множество вызовов \Ѵіп32 
АРІ. Наиболее важные вызовы перечислены в табл. 11.18. Чтобы создать дескрип¬ 
тор защиты, для него сначала выделяется место хранения, после чего он инициа¬ 
лизируется с помощью вызова ІігНлаІігеБесигіІуОезсгірІог. Этот вызов заполняет 
заголовок. Если 5Ш владельца неизвестен, он может быть найден по имени при 
помощи вызова І_оокирАссоип1:5і<1 Затем он может быть вставлен в дескриптор 
защиты. То же самое справедливо для 5Ш группы, если группа существует. Как 
правило, используется 5ГО вызывающего процесса, а также 5ГО одной из групп 
вызывающего процесса, но системный администратор может записать в дескрип¬ 
тор защиты любой 5Ш. 

Список ЭАСЬ или 5 АСЬ дескриптора защиты может быть проинициализиро- 
ван при помощи функции Іпіііаі ілеАсІ . Элементы списка АСЬ могут быть добав¬ 
лены с помощью функций АсісІАссеззАІ 1 омесІАсе и АсісІАссеззОепіесІАсе. К этим вызовам 
можно обращаться многократно, чтобы добавить столько записей АСЕ, сколько 
необходимо. Удаление записи происходит при помощи функции ОеІеІеАсе. Когда 
список АСЬ готов, его можно присоединить к дескриптору защиты с помощью 
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функции 5е1:5есигі1:у0езсп'р1:ог0ас1. Наконец, когда объект создан, к нему можно 
присоединить новенький дескриптор защиты. 


Таблица 11 . 18 . Основные функции ѴѴІп32 АРІ для управления защитой 


Функция 


Описание 


Іпі(іаІІ2е5есигі(уОезсгір(ог 

І_оокирАссоип(ЗісІ 

ЗеІЗесигіІуОезсгіріогОѵѵпег 

ЗеіЗесипТуОезсгіріогСгоир 

ІпіІіаІігеАсІ 

АсІсІАссеззАІІоѵѵесІАсе 

АсШАссеззОепіеОАсе 

ОеІеіеАсе 

ЗеІЗесигіІуОезсгірІогОасІ 


Подготовить новый дескриптор защиты 
Найти ЗЮ по заданному имени пользователя 
Ввести ЗЮ владельца в дескриптор защиты 
Ввести ЗЮ группы в дескриптор защиты 
Инициализировать ОАСЬ или ЗАСЬ 

Добавить к ОАСЬ или 5АСІ_ новый АСЕ с разрешением доступа 
Добавить к ОАСЬ или ЗАСЬ новый АСЕ с запретом доступа 
Удалить АСЕ из йАСЬ или ЗАСЬ 
Добавить ОАСЬ к дескриптору защиты 


Реализация защиты 

Защита в автономной системе \ѴіпсІо\Ѵ5 2000 реализуется при помощи нескольких 
компонентов, большую часть которых мы уже рассмотрели (вопросы сетевой без¬ 
опасности представляют собой совсем другую историю и выходит за рамки данной 
книги). Регистрацией в системе управляет программа тпІо§оп , а аутентификацией 
занимаются Ізазз и тз^іпа.М (см. раздел «Загрузка \Ѵіпс1о\ѵз 2000» данной главы). 
Результатом успешной регистрации в системе является новая оболочка с ассоци¬ 
ированным с ней маркером доступа. Этот процесс использует в реестре ключи 
5ЕСІІШТѴ и ЗАМ. Первый ключ определяет общую политику безопасности, а вто¬ 
рой ключ содержит информацию о защите для индивидуальных пользователей. 

Как только пользователь регистрируется в системе, выполняется операция 
защиты при открытии объекта. Для каждого вызова ОрепХХХ требуется имя откры¬ 
ваемого объекта и набор прав доступа к нему. Во время обработки процедуры от¬ 
крытия объекта менеджер безопасности (см. рис. 11.2) проверяет наличие у вызы¬ 
вающего процесса соответствующих прав доступа. Для этого он просматривает все 
маркеры доступа вызывающего процесса, а также список ОАСЬ, ассоциированный 
с объектом. Он просматривает по очереди элементы списка АСЬ. Как только он 
находит запись, соответствующую идентификатору 5ГО вызывающего процесса 
или одной из его групп, поиск прав доступа считается законченным. Если вызыва¬ 
ющий процесс обладает необходимыми правами, объект открывается, в противном 
случае в открытии объекта отказывается. 

Помимо разрешающих записей, списки О АСЬ могут также содержать запре¬ 
щающие записи. Поскольку менеджер безопасности прекращает поиск, наткнув¬ 
шись на первую запись с указанным идентификатором, запрещающие записи по¬ 
мещаются в начало списка ПАСЬ, чтобы пользователь, которому строго запрещен 
доступ к какому-либо объекту, не смог получить его как член какой-либо группы, 
которой этот доступ предоставлен. 

После того как объект открыт, дескриптор объекта возвращается вызываю¬ 
щему процессу. При последующих обращениях проверяется только, входит ли 
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данная операция в число операций, разрешенных в момент открытия объекта, что¬ 
бы, например, не допустить записи в файл, открытый для чтения. 


Кэширование в ѴѴіпсіоѵѵз 2000 

В операционной системе \УіпсІо\У5 2000, как и в других операционных системах, 
кэш используется для повышения производительности. Однако устройство менед¬ 
жера кэша обладает некоторыми необычными свойствами, которые стоит кратко 
рассмотреть. 

Работа менеджера кэша заключается в том, чтобы хранить в памяти недавно 
использовавшиеся блоки файловой системы и тем самым сокращать время дос¬ 
тупа при последующих обращениях к ним. В \Утсіо\ѵ5 2000 есть единый интегри¬ 
рованный кэш, обслуживающий все используемые файловые системы, включая 
ШТ5, РАТ-32, РАТ-16 и даже файловую систему для СБ-К.ОМ. Это означает, что 
файловые системы не должны управлять собственными кэшами. 

В результате менеджер кэша оказывается расположенным в системе в несколь¬ 
ко необычном месте (см. рис. 11.2). Он не является частью файловой системы, так 
как существует несколько независимых файловых систем, у которых может не 
быть ничего общего. Вместо этого он работает на более высоком уровне, чем фай¬ 
ловые системы, формально представляющие собой драйверы, управляемые менед¬ 
жером ввода-вывода. 

В основе организации кэша \ѴіпсІо\ѵ5 2000 лежат не физические блоки, а вир¬ 
туальные блоки. Чтобы понять, что это означает, вспомним, что традиционные 
файловые кэши отслеживают блоки с помощью адресов, состоящих из двух час¬ 
тей (раздел, блок), где первое число означает устройство и раздел, а второе число 
представляет собой номер блока в пределах этого дискового раздела. Менеджер 
кэша в операционной системе \УіпсІо\ѵ5 2000 этого не делает. Вместо этого при 
обращении к блоку он использует пару (файл, смещение). (Формально кэширу¬ 
ются не файлы, а потоки данных, но мы проигнорируем эту деталь.) 

Причина такого неортодоксального устройства заключается в том, что при по¬ 
ступлении запроса к менеджеру кэша в нем указывается пара (файл, смещение), 
так как это вся информация, доступная вызывающему процессу. Если бы блоки 
в кэше помечались как (раздел, блок), у менеджера кэша не было бы способа опре¬ 
делить, какой блок, заданный парой (файл, смещение), какой паре (раздел, блок) 
соответствует, так как подобным преобразованием занимается файловая система. 

Рассмотрим, как работает менеджер кэша. Когда происходит обращение к фай¬ 
лу, менеджер кэша отображает файл на 256-килобайтный фрагмент виртуального 
адресного пространства ядра. Если размер файла больше 256 Кбайт, тогда отобра¬ 
жается только часть файла. Общий размер виртуального адресного пространства, 
которое может использовать менеджер кэша, определяется в момент загрузки опе¬ 
рационной системы и зависит от объема оперативной памяти. Если менеджеру 
кэша не хватает 256 Кбайт виртуального адресного пространства, он должен, преж¬ 
де чем отображать на память новый файл, прекратить отображение на адресное 
пространство памяти предыдущего файла. 
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Как только файл отображен на память, менеджер кэша может удовлетворить 
запросы к его блокам, просто копируя фрагменты памяти из виртуального адрес¬ 
ного пространства ядра в буфер пользователя. Если копируемый блок не находит¬ 
ся в физической памяти, происходит страничное прерывание, в результате кото¬ 
рого менеджер памяти удовлетворяет страничное прерывание обычным способом. 
Менеджеру кэша даже не известно, был блок в кэше или нет. Операция копирова¬ 
ния всегда завершается успешно. 

Работа менеджера кэша для случая файловой системы на диске 5С5І и файло¬ 
вой системы РАТ-32 на диске ШЕ проиллюстрирована на рис. 11.26. Когда про¬ 
цесс читает файл, запрос направляется менеджеру кэша. Если требуемый блок ока¬ 
зывается в кэше, он немедленно копируется пользователю. Если блока в кэше нет, 
при попытке копирования блока происходит страничное прерывание. После обра¬ 
ботки страничного прерывания блок копируется вызывавшему процессу. 



Рис. 11.26. Путь сквозь кэш к апперетуре 


В результате применения такой схемы менеджер кэша не знает, сколько из ото¬ 
бражаемых им страниц находятся в физической памяти и даже насколько велик 
кэш. Только менеджер памяти обладает точной информацией. Такой подход по¬ 
зволяет менеджеру памяти динамически менять размер кэша, увеличивая и умень¬ 
шая тем самым количество страниц, выделяемых пользовательским процессам. 
Если обращений к файлам немного, но в памяти компьютера находится много 
активных процессов, менеджер памяти может отвести большую часть физической 
памяти под страницы процессов. С другой стороны, если процессов мало, а актив¬ 
ность файловой системы высокая, больше физической памяти может быть выде¬ 
лено для кэша. 
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Другое свойство менеджера кэша состоит в том, что он следит за соответстви¬ 
ем файлов, отображенных на память, файлам, открытым для чтения и записи. Рас¬ 
смотрим, например, ситуацию, в которой один процесс открывает какой-либо файл 
для чтения и записи, а второй процесс отображает этот же файл на свое адресное 
пространство. Что произойдет, если второй процесс напрямую запишет данные 
в этот файл, непосредственно перед тем, как первый процесс прочитает только 
что измененный блок? Получит ли он устаревшие данные? 

В обоих случаях — как для открытых файлов, так и для файлов, отображенных 
на память, — менеджер кэша отображает на файл 256-килобайтный участок своего 
виртуального адресного пространства. Файл отображается на память только один 
раз, независимо от того, сколько процессов откроют его или отобразят на свое 
адресное пространство. Когда от пользовательского процесса поступает запрос, 
менеджер кэша просто копирует страницу из памяти в буфер пользовательского 
процесса. Поэтому копируемая страница всегда отражает текущее состояние 
файла, так как менеджер кэша использует те же страницы, что и процесс, отобра¬ 
жающий файл на память. 

Резюме 

Структура операционной системы \УіпсІо\ѵ5 2000 включает в себя уровень аппа¬ 
ратных абстракций НАС, ядро, исполняющую систему и тонкий уровень систем¬ 
ных служб, перехватывающий входящие системные вызовы. Кроме того, опера¬ 
ционная система содержит множество драйверов устройств, включая файловую 
систему и интерфейс графических устройств СОІ. Уровень НАЬ скрывает от 
верхних уровней определенные различия в аппаратуре. Ядро пытается скрыть от 
исполняющей системы остальные различия, чтобы сделать ее почти полностью 
машинно-независимой. 

В основе исполняющей системы лежат объекты памяти. Пользовательские 
процессы создают их и получают дескрипторы, позволяющие управлять этими 
объектами. Компоненты исполняющей системы также могут создавать объекты. 
Менеджер объектов управляет пространством имен, в которое могут добавляться 
объекты для возможности их поиска по имени. 

Операционная система \УіпсІо\ѵ5 2000 поддерживает процессы, задания, пото¬ 
ки и волокна. У процессов есть виртуальные адресные пространства, кроме того, 
процессы являются контейнерами ресурсов. Потоки представляют собой едини¬ 
цы исполнения и планируются операционной системой. Волокна являются уп¬ 
рощенными потоками, планируемыми полностью в пространстве пользователя. 
Задания представляют собой наборы процессов и используются для выделения 
квот ресурсов. При планировании используется приоритетный алгоритм, в кото¬ 
ром управление получает готовый поток с максимальным приоритетом. 

Операционной системой ^Уіпбошз 2000 поддерживается виртуальная память 
с подкачкой по требованию. Алгоритм подкачки основан на понятии рабочего набо¬ 
ра. Система управляет несколькими списками свободных страниц, так что когда 
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происходит страничное прерывание, как правило, у системы уже есть доступная 
страница. Списки свободных страниц получают страницы, отнимаемые у рабочих 
наборов при помощи сложных алгоритмов, пытающихся изымать в первую оче¬ 
редь давно не использовавшиеся страницы. 

Ввод-вывод осуществляется драйверами устройств, согласующимися с моде¬ 
лью АѴіпсіо\ѵ5 Огіѵег Мосіеі. При запуске каждого драйвера инициализируется 
объект драйвера, содержащий адреса процедур, к которым может обращаться опе¬ 
рационная система, чтобы добавить новое устройство или выполнить операцию 
ввода-вывода. Драйверы могут собираться в стеки или действовать как фильтры. 

В основе файловой системы ЫТР5 лежит главная файловая таблица МРТ, в ко¬ 
торой содержится по одной записи для каждого файла или каталога. У каждого 
файла есть множество атрибутов, которые могут храниться в записи таблицы МРТ 
или вне ее, на диске. Среди прочих возможностей файловая система РГТР5 под¬ 
держивает сжатие и шифрование. 

Защита основывается на списках управления доступом АСЬ. У каждого про¬ 
цесса есть маркер управления доступом, идентифицирующий процесс, а также 
указывающий, какими особыми привилегиями он обладает. С каждым объектом 
ассоциирован дескриптор защиты. Дескриптор защиты указывает на список раз¬ 
граничительного управления доступом ОАСЬ, содержащий записи списка АСЬ, 
разрешающие или запрещающие доступ к этому объекту отдельным пользовате¬ 
лям или группам. 

Наконец, операционная система \УіпсІо\Ѵ5 2000 управляет единым для всех 
файловых систем кэшем, представляющим собой скорее виртуальный кзш, неже¬ 
ли физический. Запросы к дисковым блокам сначала поступают в кэш. Если нуж¬ 
ных блоков там нет, тогда вызывается соответствующая файловая система. 


Вопросы 

1. Назовите одно преимущество и один недостаток использования реестра 
вместо отдельных файлов іпі. 

2. У мыши может быть 1, 2 или 3 кнопки. Используются все три типа мыши. 
Скрывает ли эти различия уровень НАЕ от остальной части операционной 
системы? Почему да или почему нет? 

3. Уровень НАЬ поддерживает дату, начиная от года 1601. Приведите пример 
приложения, в котором это свойство полезно. 

4. Подсистема Р05ІХ нужна для реализации сигналов в стиле ІШІХ. Если 
пользователь нажмет клавишу для сигнала Оиіі, будет ли он планироваться 
как БРС или АРС? 

5. Многие компоненты исполняющей системы (см. рис. 11.2) обращаются к дру¬ 
гим компонентам исполняющей системы. Приведите три примера вызова 
одним компонентом другого компонента, но используйте различные компо¬ 
ненты (шесть компонентов). 
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6. В интерфейсе \Ут32 нет сигналов. Если бы сигналы были введены, они мог¬ 
ли бы относиться к процессам, потокам, и к тем и к другим, ни к тем, ни к 
другим. Выскажите свое предложение, к чему их отнести, и объясните, чем 
хороша ваша идея. 

7. Альтернатива использования БЬЬ заключается в том, чтобы статически 
компоновать каждую программу точно с теми библиотечными процедура¬ 
ми, к которым она обращается. Если бы было нужно внедрить эту схему, где 
бы это имело больший смысл, на клиентах или на серверах? 

8. Файл пЫІЫІІ экспортирует 1179 функциональных вызовов, тогда как файл 
пшкті.ехе экспортирует 1209 функциональных вызовов. Является ли это 
ошибкой? Чем может быть вызвано это различие? 

9. Объекты, управляемые менеджером объектов, имеют переменный размер, 
у различных объектов могут быть разные размеры. Может ли объект начи¬ 
наться с произвольного байта в невыгружаемом пуле? Подсказка: для отве¬ 
та на этот вопрос не требуется дополнительной информации об операцион¬ 
ной системе \Уикіо\Ѵ5 2000, кроме той, что была дана в тексте. 

10. Существует ли ограничение на число различных операций, которые могут 
быть определены для исполняющего объекта? Если да, то какова природа 
этого ограничения? Если нет, то почему? 

11. Вызов интерфейса \Ут32 ИаЧРогМиІІірІеОЬо'есІз позволяет потоку блокиро¬ 
ваться на множестве объектов синхронизации, чьи дексрипторы передают¬ 
ся этой функции в виде параметров. Вызывающий поток отпускается, как 
только один из этих объектов получает сигнал. Может ли набор объектов 
синхронизации включать в себя два семафора, один мьютекс и одну крити¬ 
ческую область? Почему да или почему нет? Подсказка: этот вопрос требует 
тщательного обдумывания. 

12. Назовите три причины, по которым процесс может завершиться. 

13. Рассмотрите ситуацию на рис. 11.8, в которой система собирается планиро¬ 
вать поток. Если предположить, что каждый поток ограничен по скорости 
вычислений, то сколько времени пройдет, прежде чем поток с приоритетом 3 
получит управление в операционной системе \ѴіпсІо\ѵ5 2000 Ргоіеззіопаі? 

14. Допустим, что квант времени установлен равным 20 мс и что текущий по¬ 
ток с приоритетом 24 только что начал свой квант. Внезапно операция вво¬ 
да-вывода завершается, и поток с приоритетом 28 переходит в состояние 
готовности. Сколько времени придется ему ждать обслуживания? 

15. В операционной системе \Уіпсіо\у5 2000 текущий приоритет всегда больше 
базового приоритета или равен ему. Существуют ли обстоятельства, при 
которых имел бы смысл приоритет ниже базового? Если да, то приведите 
пример. Если нет, то почему нет? 

16. Некоторые программы для операционной системы МЗ-БОЗ были напи¬ 
саны на ассемблере, с использованием таких команд, как ^ и 01Л, для об¬ 
ращения к портам. Может ли такая программа выполняться в системе 
\УтсІо\ѵ5 2000? Если нет, то можете ли вы придумать способ поддержки по¬ 
добных программ? 
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17. Назовите два способа получения лучшего времени отклика для важных 
процессов. 

18. В тексте главы кратко обсуждался позиционно-независимый код. Эта тех¬ 
нология применяется для того, чтобы два процесса могли совместно исполь¬ 
зовать одну и ту же процедуру в различных виртуальных адресах. Можно 
ли решить эту проблему при помощи простой настройки таблиц страниц 
двух процессов? Аргументируйте свой ответ. 

19. В операционной системе АѴшсІо\ѵз 2000 совместно используемые библиоте¬ 
ки хранятся в файлах .(III, которые могут одновременно отображаться раз¬ 
личными процессами на свои адресные пространства. Проблема может воз¬ 
никнуть, когда два процесса захотят отобразить одну и ту же библиотеку по 
различным виртуальным адресам. Как может быть решена зта проблема на 
компьютере с процессором Репііиш, учитывая свойство архитектуры его 
памяти? Если это решение требует изменений в реализации \Уіпс1о\ѵз 2000, 
перечислите эти изменения. 

20. Если область виртуального адресного пространства зарезервирована, но не 
фиксирована, как вы думаете, создается ли для нее описатель виртуальной 
памяти ѴАБ? Аргументируйте свой ответ. 

21. Какие из переходов, показанных на рис. 11.14, представляют собой поли¬ 
тические решения, в отличие от переходов, вынуждаемых системными со¬ 
бытиями (например, процесс завершает работу, и его страницы освобож¬ 
даются)? 

22. Предположим, страница используется совместно одновременно в двух 
рабочих наборах. Куда она попадает (см. рис. 11.14), если удаляется из одно¬ 
го из рабочих наборов? 

23. Когда процесс освобождает чистую страницу, он выполняет переход (5) на 
рис. 11.14. Почему нет перехода в список модифицированных страниц, ког¬ 
да освобождается «грязная» страница? 

24. Допустим, что 32-разрядное слово может быть прочитано или записано 
за 10 нс в оперативную память или видеопамять. Сколько времени потребу¬ 
ется, чтобы нарисовать фон для экрана ХСА в лучшем случае? 

25. Файл размещается на диске следующим образом. Какими будут записи се¬ 
рий блоков в таблице МЕТ? 

Ойзеі: 0123456789 10 

Оізк асМгезз 50 51 52 22 24 25 26 53 54 - 60 

26. Рассмотрите запись таблицы МЕТ на рис. 11.18. Предположим, файл вырос 
и к концу файла был добавлен 10-й блок. Номер этого блока 66. Как теперь 
будет выглядеть запись МЕТ? 

27. На рис. 11.22,6 первые два сегмента файла имеют длину по 8 блоков. Явля¬ 
ется ли равенство их размеров случайностью, или же это объясняется свой¬ 
ствами работы алгоритма сжатия? Аргументируйте свой ответ. 
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28. Допустим, вы решили создать облегченную версию операционной системы 
"\Ѵіпс1о\ѵ5 2000. Какие поля из перечисленных на рис. 11.24 можно удалить, 
не ослабляя защиты системы? 

29. Во всех текущих версиях Ѵ/іпс1о\ѵ8 с помощью команды ге^есііі можно экспор¬ 
тировать часть или весь реестр в текстовый файл. Сохраните реестр в виде 
текстового файла несколько раз во время работы и посмотрите, какие изме¬ 
нения в нем обнаружатся. Если у вас есть доступ к компьютеру с операцион¬ 
ной системой "\Ѵіпс1о\ѵ5, на котором вы можете устанавливать программное 
или аппаратное обеспечение, определите, какие изменения появятся в реес¬ 
тре при добавлении или удалении программы или устройства. 

30. Напишите программу для операционной системы ІЖІХ, имитирующую за¬ 
пись в файл ІѵГГРЗ с несколькими потоками данных. В качестве аргументов 
эта программа должна принимать список из одного или нескольких файлов. 
Эта программа должна создавать выходной файл, в котором один поток дол¬ 
жен содержать атрибуты всех аргументов, а дополнительные потоки — содер¬ 
жимое каждого из аргументов. Затем напишите вторую программу, сообща¬ 
ющую об атрибутах и потоках и извлекающую все компоненты. 

31. Напишите программу, формирующую имя формата МЗ-БОЗ 8+3 по задан¬ 
ному имени файла. Используйте алгоритм \Уіпс1о\ѵ5 2000. 




Глава 12 
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В предшествующих 11 главах мы рассмотрели большое количество материала и 
познакомились со множеством понятий и примеров, имеющих отношение к опе¬ 
рационным системам. Однако разработка новой операционной системы отличает¬ 
ся от изучения существующих операционных систем. В этой главе мы собираемся 
обсудить несколько вопросов, которые должны учитывать разработчики новых 
операционных систем. 

В среде разработчиков операционных систем ходит множество изустных пре¬ 
даний о том, что такое хорошо и что такое плохо, однако на удивление малое 
количество из этих историй записано. Наиболее важной книгой можно назвать 
классический труд Фреда Брукса [44], в котором автор делится своим опытом 
проектирования и реализации операционной системы ІВМ 05/360. Материал 
выпущенного к 20-летней годовщине издания был пересмотрен, к тому же в со¬ 
держание книги было включено несколько новых глав [46]. Вероятно, единствен¬ 
ной книгой по операционным системам, в которой серьезно обсуждается тема про¬ 
ектирования, является [80]. 

Тремя классическими трудами по проектированию операционных систем явля¬ 
ются [194, 74, 286]. Как и книги Брукса, эти три статьи успешно пережили время, 
прошедшее с момента их написания. Большая часть рассматриваемых в них воп¬ 
росов сохранила свою актуальность и в наши дни. 

Данная глава основана на содержимом этих источников, кроме того, в ней ис¬ 
пользуется личный опыт участия автора в проектировании трех систем: АшоеЬа 
[324], МШІХ [326] и СІоЬе [340]. Поскольку среди разработчиков операционных 
систем нет единого мнения по вопросу о том, как лучше всего проектировать опе¬ 
рационные системы, эта глава будет носить более личный характер, более умозри¬ 
тельный и, несомненно, более противоречивый, чем предыдущие главы. 


Природа проблемы проектирования 

Разработка операционных систем представляет собой в большей мере инженер¬ 
ный проект, нежели точную науку. В этой области значительно труднее наметить 
ясные цели и достичь их. Рассмотрим для начала вопрос постановки задачи. 
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Цели 

Чтобы проект операционной системы был успешным, разработчики должны иметь 
четкое представление о том, чего они хотят. При отсутствии цели очень трудно 
принимать последующие решения. Чтобы этот вопрос стал понятнее, полезно 
взглянуть на два языка программирования, РИ/1 и С. Язык РЬ/1 был разработан 
корпорацией ІВМ в 60-е годы, так как поддерживать одновременно РОК.ТК.АМ и 
СОВОЬ и слушать при этом за спиной ворчание ученых о том, что А1§о1 лучше, 
чем РОК.ТК.АМ и СОВОЬ вместе взятые, было невыносимо. Поэтому был создан 
комитет для создания нового языка, удовлетворяющего запросам всех программи¬ 
стов: РЬ/1. Этот язык обладал некоторыми чертами языка РОК.ТК.АМ, некоторы¬ 
ми особенностями языка СОВОЬ и некоторыми свойствами языка А1§о1. Проект 
потерпел неудачу, потому что ему недоставало единой концепции. Проект пред¬ 
ставлял собой лишь набор свойств, конфликтующих друг с другом, к тому же язык 
РЬ/1 был слишком громоздким и неуклюжим, чтобы программы на нем можно 
было эффективно компилировать. 

Теперь взглянем на язык С. Он был спроектирован всего одним человеком 
(Деннисом Ритчи) для единственной цели (системного программирования). 
Успех его был колоссален, и это не в последнюю очередь объяснялось тем, что 
Ритчи знал, чего хотел и чего не хотел. В результате спустя десятилетия после сво¬ 
его появления этот язык все еще широко распространен. Наличие четкого пред¬ 
ставления о своих целях является решающим. 

Чего же хотят разработчики операционных систем? Очевидно, ответ варьиру¬ 
ется от системы к системе и будет разным для встроенных систем и серверных 
систем. Для универсальных операционных систем основными являются следую¬ 
щие четыре пункта: 

1. Определение абстракций. 

2. Предоставление примитивных операций. 

3. Обеспечение изоляции. 

4. Управление аппаратурой. 

Ниже будет рассмотрен каждый из этих пунктов. 

Наиболее важная, но, вероятно, наиболее сложная задача операционной систе¬ 
мы заключается в определении правильных абстракций. Некоторые из них, такие 
как процессы и файлы, уже используются так давно, что могут показаться очевид¬ 
ными. Другие, такие как потоки исполнения, представляют собой более новые и 
потому не столь устоявшиеся понятия. Например, если состоящий из нескольких 
потоков процесс, один из потоков которого блокирован вводом с клавиатуры, кло¬ 
нируется, то должен ли поток в новом процессе также ожидать ввода с клавиату¬ 
ры? Другие абстракции относятся к синхронизации, сигналам, модели памяти, 
моделированию ввода-вывода и иным областям. 

Каждая абстракция может быть реализована в виде конкретных структур дан¬ 
ных. Пользователи могут создавать процессы, файлы, семафоры ит. д. Управля¬ 
ют этими структурами данных при помощи примитивных операций. Например, 
пользователи могут читать и писать файлы. Примитивные операции реализуются 
в виде системных вызовов. С точки зрения пользователя, сердце операционной 
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системы формируется абстракциями, а операции над ними возможны при помо¬ 
щи системных вызовов. 

Поскольку на одном компьютере могут одновременно зарегистрироваться не¬ 
сколько пользователей, операционная система должна предоставлять механизмы 
для отделения их друг от друга. Один пользователь не должен вмешиваться в ра¬ 
боту другого. Для группирования ресурсов с целью их защиты широко применя¬ 
ется концепция процессов. Как правило, также защищаются файлы и другие струк¬ 
туры данных. Ключевая цель проектирования операционной системы заключается 
в том, чтобы гарантировать, что каждый пользователь может выполнять только 
разрешенные ему действия с данными, к которым у него есть право доступа. Однако 
пользователям также бывает необходимо совместное использование данных и ре¬ 
сурсов, поэтому изоляция должна быть избирательной и контролироваться пользо¬ 
вателями. Все это существенно усложняет устройство операционной системы. 

С этим вопросом тесно связана проблема необходимости изолирования отказов. 
Если какая-либо часть системы выйдет из строя (чаще всего это один из пользова¬ 
тельских процессов), сбойный процесс не должен нарушить работу всей операци¬ 
онной системы. Устройство операционной системы должно гарантировать надеж¬ 
ную изоляцию различных частей операционной системы друг от друга. 

Наконец, операционная система должна управлять аппаратурой. В частности, 
она должна заботиться обо всех низкоуровневых микросхемах, таких как контрол¬ 
леры прерываний и контроллеры шин. Она также должна обеспечивать каркас для 
того, чтобы драйверы устройств могли управлять крупными устройствами ввода- 
вывода, такими как диски, принтеры и дисплей. 

Почему так сложно спроектировать 
операционную систему? 

Закон Мура гласит, что аппаратное обеспечение компьютера увеличивает свою 
производительность в 100 раз каждые десять лет. Никто, к сожалению, так и не 
сформулировал ничего подобного для программного обеспечения. Никто и не гово¬ 
рит, что операционные системы вообще совершенствуются с годами. В самом деле, 
можно утверждать, что некоторые из них даже стали хуже в определенных аспек¬ 
тах (таких как надежность), чем, например, операционная система ІЖІХ Ѵегзіоп 7 
образца 70-х годов. 

Почему? Как правило, основными причинами оказываются инерция и желание 
сохранить обратную совместимость, хотя неумение разработчиков придерживаться 
принципов хорошего проектирования тоже вносит свою лепту. Но этот вопрос сле¬ 
дует обсудить подробнее. Операционные системы принципиально отличаются от 
небольших прикладных программ, продающихся в компьютерных магазинах за 
49 долларов. Рассмотрим восемь аспектов, благодаря которым разработка операцион¬ 
ной системы оказывается значительно сложнее написания прикладной программы. 

Во-первых, операционные системы стали крайне громоздкими программами. 
Никто в одиночку не может, засев за персональный компьютер на несколько ме¬ 
сяцев, написать операционную систему. Все современные версии ІЖІХ превосхо¬ 
дят 1 млн строк исходного текста. Операционная система \Ѵіпбо\ѵз 2000 состоит 
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из 29 млн строк кода. Ни один человек на Земле не способен понять даже одного 
миллиона строк, не говоря уже о 29 миллионах. Если вы создаете продукт, который 
ни один из разработчиков не может даже надеяться понять целиком, не удивитель¬ 
но, что результаты часто оказываются далеки от оптимальных. 

Операционные системы не являются самыми сложными системами в мире. 
Например, авианосцы представляют собой значительно более сложные системы, 
но они легче разделяются на отдельные подсистемы. Проектировщики туалетов 
на авианосце не должны заниматься радарной системой. Эти две подсистемы по¬ 
чти не взаимодействуют. В операционной системе файловая система часто взаи¬ 
модействует с системой памяти самым неожиданным и непредсказуемым образом. 

Во-вторых, операционные системы должны иметь дело с параллелизмом. В сис¬ 
теме одновременно присутствует множество пользователей, работающих с множе¬ 
ством устройств ввода-вывода. Управление несколькими параллельно выполня¬ 
ющимися процессами существенно сложнее управления одной последовательной 
деятельностью. Среди множества возникающих при этом проблем достаточно на¬ 
звать хотя бы состязания и тупиковые ситуации. 

В-третьих, операционные системы должны учитывать наличие потенциально 
враждебных пользователей — пользователей, желающих вмешиваться в работу 
операционной системы или выполнять запрещенные действия, например похище¬ 
ние чужих файлов. Операционная система должна предпринимать меры для пре¬ 
дотвращения подобных действий со стороны злонамеренных пользователей. Тек¬ 
стовые процессоры и фоторедакторы не сталкиваются с подобными проблемами. 

В-четвертых, несмотря на тот факт, что пользователи друг другу не доверяют, 
многим из них бывает нужно использовать какую-либо информацию или ресурсы 
совместно с определенной группой пользователей. Операционная система долж¬ 
на предоставлять эту возможность, но таким образом, чтобы злоумышленник не 
смог воспользоваться этими свойствами для своих целей. У прикладных программ 
подобных проблем тоже нет. 

В-пятых, операционные системы, как правило, живут довольно долгое время. 
Операционная система ІШІХ использовалась в течение четверти века; система 
\Ѵіп<іо\Ѵ5 уже используется более десяти лет и признаков умирания не обнару¬ 
живает. Соответственно, проектировщики операционной системы должны думать 
о том, как могут измениться аппаратура и приложения в отдаленном будущем 
и как им следует к этому подготовиться. Системы, отражающие одно специфичес¬ 
кое мировоззрение, как правило, быстро сходят со сцены. 

В-шестых, у разработчиков операционной системы на самом деле нет четкого 
представления о том, как будет использоваться их система, поэтому они должны 
обеспечить достаточную степень универсальности. При проектировании таких сис¬ 
тем, как ІЖІХ или \Ѵіпс1о\ѵз 2000, не предполагалось их использование для работы 
с электронной почтой или запуск \ѵеЬ-браузера под их управлением, однако мно¬ 
гие современные компьютеры в основном только для этого и используются. Труд¬ 
но себе представить проектировщика морского судна, который не знал бы, что он 
проектирует: рыболовецкое судно, пассажирское судно или военный корабль. 

В-седьмых, от современных операционных систем, как правило, требуется 
переносимость, что означает возможность работы на различных платформах. Они 
также должны поддерживать сотни или даже тысячи устройств ввода-вывода, 
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которые проектируются совершенно независимо друг от друга. Например, опера¬ 
ционная система должна работать на компьютерах как с прямым, так и с обрат¬ 
ным порядком байтов. Второй пример постоянно наблюдался в системе М5-Б05, 
когда пользователи пытались установить звуковую карту и модем, использующие 
одни и те же порты ввода-вывода или линии запроса прерывания. С такими 
проблемами, как конфликты различных частей аппаратуры, приходится иметь 
дело в основном именно операционным системам. 

Наконец, в-восьмых, при разработке операционных систем часто учитывается 
необходимость совместимости с предыдущей версией операционной системы. 
Система может иметь множество ограничений па длину слов, имена файлов 
и т. д., рассматриваемых теперь проектировщиками как устаревшие, но от которых 
трудно избавиться. Это напоминает переоборудование автомобильного завода под 
выпуск новых моделей с условием сохранения текущих мощностей по выпуску 
старых моделей. 


Разработка интерфейса 

Итак, теперь должно быть ясно, что написание современной операционной систе¬ 
мы представляет собой непростую задачу. Но с чего начинается эта работа? Воз¬ 
можно, лучше всего сначала подумать о предоставляемых операционной системой 
интерфейсах. Операционная система предоставляет набор служб, большую часть 
типов данных (например, файлы) и множество операций с ними (например, геай). 
Вместе они формируют интерфейс для пользователей системы. Обратите внима¬ 
ние, что в данном контексте пользователями операционной системы являются 
программисты, пишущие программы, которые используют системные вызовы, 
а не люди, запускающие прикладные программы. 

Кроме основного интерфейса системных вызовов, у большинства операцион¬ 
ных систем есть дополнительные интерфейсы. Например, некоторым программи¬ 
стам бывает необходимо написать драйвер устройства, чтобы добавить его в опе¬ 
рационную систему. Эти драйверы предоставляют определенные функции и могут 
обращаться к определенным системным вызовам. Функции и вызовы определяют 
интерфейс, существенно отличающийся от используемого прикладными програм¬ 
мистами. Все эти интерфейсы должны быть тщательно спроектированы, если раз¬ 
работчики системы рассчитывают на успех. 

Руководящие принципы 

Существуют ли принципы, руководствуясь которыми можно проектировать ин¬ 
терфейсы? Мы надеемся, что такие принципы есть. Если выразить их в несколь¬ 
ких словах, то это простота, полнота и возможность эффективной реализации. 

Принцип 1. Простота 

Простой интерфейс легче понять и реализовать без ошибок. Всем разработчикам 
систем следует помнить эту знаменитую цитату французского летчика и писателя 
Антуана де Сент-Экзюпери: 
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Совершенство достигается не тогда, когда уже больше нечего добавить, а когда 
больше нечего убавить. 

Этот принцип утверждает, что лучше меньше, чем больше, по крайней мере, 
применительно к операционным системам. Другими словами, этот принцип может 
быть выражен следующей аббревиатурой, предлагающей программисту, в чьих 
мыслительных способностях возникают сомнения, не усложнять систему: КІ55 
(Кеер И Зітріе, ЗіирісІ). 

Принцип 2. Полнота 

Разумеется, интерфейс должен предоставлять пользователям возможность выпол¬ 
нять все, что им необходимо, то есть интерфейс должен обладать полнотой. В свя¬ 
зи с этим на ум приходит другая цитата, на этот раз это фраза, сказанная Альбер¬ 
том Эйнштейном: 

Все должно быть простым, насколько это возможно, но не проще. 

Другими словами, операционная система должна выполнять то, что от нее тре¬ 
буется, но не более того. Если пользователю нужно хранить данные, операционная 
система должна предоставлять для этого некий механизм. Если пользователям 
необходимо общаться друг с другом, операционная система должна предоставлять 
механизм общения и т. д. В своей речи по поводу получения награды Тигіп§ А\уагй 
один из разработчиков систем СТ55 и МЕ/ЬТІСЗ Фернандо Корбато объединил 
понятия простоты и полноты и сказал: 

Во-первых, важно подчеркнуть значение простоты и элегантности, так как 
сложность приводит к нагромождению противоречий и, как мы уже видели, появ¬ 
лению ошибок. Я бы определил элегантность как достижение заданной функцио¬ 
нальности при помощи минимума механизма и максимума ясности. 

Ключевая идея здесь — минимум механизма. Другими словами, каждая функ¬ 
ция, каждый системный вызов должны нести свою собственную ношу. Когда член 
команды проектировщиков предлагает расширить системный вызов или добавить 
новую функцию, остальные разработчики должны спросить его: «Произойдет ли 
что-нибудь ужасное, если мы этого не сделаем?» Если ответом будет: «ЕІег, но, 
возможно, когда-нибудь кто-то посчитает эту функцию полезной», поместите ее 
в библиотеку уровня пользователя, а не в операционную систему, даже если при 
этом она будет работать медленнее. Не должна ставиться задача сделать каждую 
функцию быстрее пули. Цель заключается в том, чтобы сохранить то, что Корбато 
назвал минимумом механизма. 

Давайте кратко рассмотрим два примера из моего личного опыта: операционные 
системы МШІХ и АтоеЪа. Для всех задач в системе МШІХ есть три системных 
вызова: зепф гесеіѵе и зепсігес. Система структурирована в виде набора процессов, 
с менеджером памяти, файловой системой и каждым драйвером устройства, пред¬ 
ставляющими собой отдельный планируемый процесс. В первом приближении все, 
что делает ядро, — это планирование процессов и управление передачей сообщений 
между ними. Соответственно, необходимыми являются только два системных вы¬ 
зова: зепсі для отправки сообщения и гесеіѵе, чтобы сообщение получить. Третий 
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системный вызов, зепбгес, представляет собой просто оптимизацию, позволяющую 
послать сообщение и запросить ответ всего за одно эмулированное прерывание. 
Все остальное в системе выполняется с помощью обращения к какому-либо друго¬ 
му процессу (например, к процессу файловой системы или к дисковому драйверу). 

Операционная система АтоеЬа устроена еще проще. У нее есть только один 
системный вызов: выполнение вызова удаленной процедуры. Этот вызов отправ¬ 
ляет сообщение и ждет ответа. По существу, это то же самое, что и системный вызов 
зепбгес в системе МШІХ. Все остальное строится на этом единственном вызове. 

Принцип 3. Эффективность 

Третий руководящий принцип представляет собой эффективность реализации. 
Если какая-либо функция (или системный вызов) не может быть реализована 
эффективно, вероятно, ее не следует реализовывать. Программист должен интуи¬ 
тивно представлять стоимость реализации и использования каждого системного 
вызова. Например, программисты, пишущие программы в системе ІЖІХ, счита¬ 
ют, что системный вызов 1$еек дешевле системного вызова геаб, так как первый 
системный вызов просто изменяет содержимое указателя, хранящегося в памя¬ 
ти, тогда как второй системный вызов выполняет операцию дискового ввода- 
вывода. Если интуиция подводит программиста, программист создает неэффек¬ 
тивные программы. 

Парадигмы 

Когда цели установлены, можно начинать проектирование. Можно начать, напри¬ 
мер, со следующего: подумать, как будет представать система перед пользователя¬ 
ми. Один из наиболее важных вопросов заключается в том, чтобы все функции 
системы хорошо согласовывались друг с другом и обладали тем, что часто на¬ 
зывают архитектурной согласованностью. При этом важно различать два типа 
«пользователей» операционной системы. С одной стороны, существуют пользова¬ 
тели, взаимодействующие с прикладными программами; с другой стороны, есть 
программисты, пишущие эти прикладные программы. Первые большей частью 
имеют дело с графическим интерфейсом пользователя, тогда как последние в основ¬ 
ном взаимодействуют с интерфейсом системных вызовов. Если задача заключается 
в том, чтобы иметь единый графический интерфейс пользователя, заполняющий 
всю систему, как, например, в системе МасіпіозЬ, тогда разработку следует начать 
отсюда. Если же цель состоит в том, чтобы обеспечить поддержку различных воз¬ 
можных графических интерфейсов пользователя, как в системе ИМХ, тогда в пер¬ 
вую очередь должен быть разработан интерфейс системных вызовов. Начало раз¬ 
работки системы с графического интерфейса пользователя представляет собой, по 
сути, проектирование сверху вниз. Вопрос заключается в том, какие функции бу¬ 
дет этот интерфейс иметь, как будет пользователь с ними взаимодействовать и как 
следует спроектировать систему для их поддержки. Например, если большинство 
программ отображает на экране значки, а затем ждет, когда пользователь щелкнет 
на них мышью, это предполагает использование управляемой событиями модели 
для графического интерфейса пользователя и, возможно, для операционной систе¬ 
мы. С другой стороны, если экран в основном заполнен текстовыми окнами, тогда, 
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вероятно, лучшей представляется модель, в которой процессы считывают симво¬ 
лы с клавиатуры. 

Реализация в первую очередь интерфейса системных вызовов представляет 
собой проектирование снизу вверх. Здесь вопросы заключаются в том, какие функ¬ 
ции нужны программистам. В действительности для поддержки графического 
интерфейса пользователя требуется не так уж много специальных функций. На¬ 
пример, оконная система под названием X \Ѵіп<іо\Ѵ5, используемая в ІЖІХ, пред¬ 
ставляет собой просто большую программу на языке С, которая обращается к кла¬ 
виатуре, мыши и экрану с системными вызовами геасі и мгііе. Оконная система 
X \Ѵіпс1о\Ѵ5 была разработана значительно позже операционной системы ІЖІХ, но 
для ее работы не потребовалось большого количества изменений в операционной 
системе. Это подтверждает тот факт, что система ІЖІХ обладает полнотой в дос¬ 
таточной степени. 

Парадигмы интерфейса пользователя 

Как для интерфейса уровня графического интерфейса пользователя, так и для ин¬ 
терфейса системных вызовов наиболее важный аспект заключается в наличии 
хорошей парадигмы (иногда называемой метафорой или модельным представле¬ 
нием), обеспечивающей наглядный зрительный образ интерфейса. Многими 
графическими интерфейсами пользователя используется парадигма \ѴІМР (\Ѵіп- 
йо\Ѵ5, Ісопз, Мепиз, Роіпіегз — окна, пиктограммы, меню, указатели), обсуждавша¬ 
яся в главе 5. Эта парадигма используется в интерфейсе для обеспечения согла¬ 
сованности таких идиом, как щелчок и двойной щелчок мышью, перетаскивание 
и т. д. Часто к программам применяются дополнительные требования, такие как 
наличие строки меню с пунктами Файл, Правка и т. д., каждый из которых содержит 
хорошо знакомые пункты меню. Таким образом, пользователи, знакомые с одной 
программой, легко могут освоить другую программу. 

Однако пользовательский интерфейс \ѴІМР не является единственно возмож¬ 
ным. В некоторых карманных компьютерах применяется интерфейс электронно¬ 
го пера. Устройства, предназначенные для мультимедиа, могут использовать ин¬ 
терфейс видеомагнитофона. И, разумеется, при управлении компьютером голосом 
используется совершенно отличная парадигма. Выбор парадигмы, конечно, важен, 
но еще важнее сам факт использования единой парадигмы, объединяющей весь 
пользовательский интерфейс. 

Какая бы парадигма ни была выбрана, существенно, чтобы все прикладные про¬ 
граммы использовали ее. Следовательно, проектировщики системы должны пре¬ 
доставить разработчикам прикладных программ библиотеки и инструменты для 
доступа к процедурам, обеспечивающим однородный внешний вид пользователь¬ 
ского интерфейса. Разработка пользовательского интерфейса представляет собой 
очень важную задачу, но она не является темой данной книги, поэтому мы вер¬ 
немся к обсуждению темы интерфейса операционной системы. 

Парадигмы исполнения 

Архитектурная согласованность важна на уровне пользователя, но в равной мере 
она важна на уровне интерфейса системных вызовов. Здесь часто полезно разли¬ 
чать парадигму исполнения от парадигмы данных, поэтому мы рассмотрим и ту 
и другую, начав с первой. 
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Широкое распространение получили две парадигмы: алгоритмическая и дви¬ 
жимая событиями. Алгоритмическая парадигма основана на идее, что программа 
запускается для выполнения некоторой функции, известной заранее или задавае¬ 
мой в виде параметров. Эта функция может заключаться в компиляции программы, 
составлении ведомости или пилотировании самолета до Сан-Франциско. Базовая 
логика жестко прошита в код программы, при этом программа время от времени 
обращается к системным вызовам, чтобы получить ввод пользователя, обратиться 
к системным службам и т. д. Этот подход проиллюстрирован в листинге 12.1, я. 

Другая парадигма исполнения представляет собой парадигму управления со¬ 
бытиями (листинг 12.1, б). Здесь программа выполняет определенную инициали¬ 
зацию, например, отображает какое-либо окно, а затем ждет, когда операционная 
система сообщит ей о первом событии. Этим событием может быть нажатие кла¬ 
виши или перемещение мыши. Такая схема полезна для программ, активно взаи¬ 
модействующих с пользователем. 

Листинг 12 . 1 . Алгоритмический код (а); движимый событиями код (б) 

шаіп() шаіп() 

{ { 

іггЬ ... : те55_Ь тзд: 


іпіК ): 

йо_5отеШпд(); 
геасК ...): 

сІо_5отеУтіпд_еІ5е() : 
мгііеС ...); 
кеер_доіпд(): 
ехЩО): 


а 


іпіК): 

иітііе (де1_тез5аде(&тзд)) { 
зміісН (тзд.іуре) { 
сазе 1: ... ; 
сазе 2: ... ; 
сазе 3: ... : 

} 

} 

} 

б 


Каждая парадигма порождает собственный стиль программирования. В алго¬ 
ритмической парадигме алгоритмы занимают центральное положение, а операци¬ 
онная система рассматривается как поставщик служб. В парадигме управления 
событиями операционная система также предоставляет службы, но ее основная 
роль заключается в координации активности пользователя и формировании со¬ 
бытий, потребляемых процессами. 


Парадигмы данных 

Парадигма исполнения является не единственной парадигмой, экспортируемой 
операционной системой. Не менее важна парадигма данных. Ключевой вопрос 
здесь заключается в том, как предстают перед программистом системные структу¬ 
ры и устройства. В ранних пакетных системах, предназначенных для выполнения 
программ на языке РОКТКАІѴ, все моделировалось как логическая магнитная лен¬ 
та. Считываемые колоды карт воспринимались как входные ленты, пробиваемые 
колоды карт обрабатывались как выходные ленты. Вывод на принтер также обра¬ 
батывался как выходная лента. Файлы на диске также считались лентами. Произ¬ 
вольный доступ к файлу был возможен только при помощи перемотки соответ¬ 
ствующей ленты и повторного считывания. 
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Задание запускалось при помощи карт управления заданием, например: 

МОШ(ТАРЕ08. КЕЕІ_781) 

ШШРІЛ. МУРАТА. 01ЛР1Л. РУМСН. ТАРЕ08) 

Первая карта представляла собой инструкцию для оператора. Он должен был дос¬ 
тать из шкафа бобину номер 781 и установить ее на накопителе 8. Вторая карта яв¬ 
лялась командой операционной системе запустить только что откомпилированную 
с языка РОКТКАИ программу, отображая ШР17Т (означающий устройство чтения 
перфокарт) на логическую ленту 1, дисковый файл МУБАТА на логическую ленту 2, 
принтер ОІІТРІІТ на логическую ленту 3, перфоратор РѴЫСН на логическую лен¬ 
ту 4 и физический накопитель на магнитной ленте ТАРЕ08 на логическую ленту 5. 

Синтаксис языка РОКТКАИ позволяет читать и писать логические ленты. При 
чтении с логической ленты 1 программа получает ввод с перфокарт. При помощи 
записи на логическую ленту 3 программа может вывести результаты на принтер. 
Обращаясь к логической ленте 5, программа может читать и писать магнитную 
ленту 781 и т. д. Обратите внимание, что идея магнитной ленты представляла собой 
всего лишь парадигму (модель) для объединения устройства чтения перфокарт, 
принтера, перфоратора, дисковых файлов и магнитофонов. В данном примере 
только логическая лента 5 была физической лентой. Все остальное представляло 
собой обычные файлы для подкачки данных. Это была примитивная парадигма, 
но она была шагом в правильном направлении. 

Затем появилась операционная система ИШХ, которая пошла значительно 
дальше в этом направлении, используя модель «все суть файлы». При использо¬ 
вании этой парадигмы все устройства ввода-вывода рассматриваются как файлы, 
которые можно открывать и управлять ими, как обычными файлами. Операторы 
на языке С 

Ш = орепС'ЕПеГ'. 0_ШР): 

ЕсІ2 = ореп( "/сіеѵ/иу" . 0_Ш): 

открывают настоящий дисковый файл и терминал пользователя. Последующие 
операторы могут использовать дескрипторы файлов /сіі и /сі2, чтобы читать из этих 
файлов и писать в них. С этого момента нет разницы между доступом к файлу и до¬ 
ступом к терминалу, не считая того, что при обращении к терминалу не разреша¬ 
ется операция перемещения указателя в файле. 

Операционная система ИШХ не только объединяет файлы и устройства вво¬ 
да-вывода, но также позволяет получать доступ к другим процессам через каналы, 
как к файлам. Более того, если поддерживается отображение файлов на адресное 
пространство памяти, процесс может обращаться к своей виртуальной памяти так, 
как если бы это был файл. Наконец, в версиях ИРПХ, поддерживающих файловую 
систему /ргос, строка на языке С 

ТсІЗ = ореп("/ргос/501". 0_ШР); 

позволяет процессу (попытаться) получить доступ к памяти процесса 501 для 
чтения и записи при помощи дескриптора файла / <ІЗ , что может быть полезно, 
например, при отладке программы. 

Операционная система \Уіп<іо\ѵ5 2000 идет в использовании этой модели еще 
дальше, представляя все, что есть в системе, в виде объектов. Получив дескриптор 
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файла, процесса, семафора, почтового ящика или другого объекта ядра, процесс 
может выполнять с этим объектом различные действия. Эта парадигма являет¬ 
ся еще более общей, чем используемая в ІЖІХ, и значительно более общей, чем 
в РОКТКАИ. 

Объединяющие парадигмы также встречаются в других контекстах. Следует 
отметить один из них: Всемирную паутину (\ѴеЬ). Используемая в Паутине пара¬ 
дигма состоит в том, что все киберпространство заполнено документами, у каждого 
их которых есть свой адрес ІШЬ. Обратившись по соответствующему указателю 
ІШЬ (введя его с клавиатуры или щелкнув мышью по ссылке), вы получаете этот 
документ. В действительности многие «документы» вовсе не являются документа¬ 
ми, но формируются программой или сценарием оболочки, когда поступает запрос. 
Например, когда пользователь запрашивает в Инетериет-магазине список компакт- 
дисков конкретного исполнителя, документ создается налету программой. Он со¬ 
вершенно точно не существовал до того, как был получен запрос. 

Итак, мы рассмотрели четыре парадигмы, а именно: все суть ленты, файлы, 
объекты или документы. Во всех четырех случаях задача заключается в том, что¬ 
бы унифицировать данные, устройства или другие ресурсы для упрощения рабо¬ 
ты с ними. Каждая операционная система должна иметь подобную унифицирую¬ 
щую парадигму данных. 

Интерфейс системных вызовов 

Если исходить из высказанного Корбато принципа минимального механизма, тогда 
операционная система должна предоставлять настолько мало системных вызовов, 
насколько это возможно (необходимый минимум), и каждый системный вызов 
должен быть настолько прост, насколько это возможно (но не проще). Объединя¬ 
ющая парадигма данных может играть главную роль в этом. Например, если фай¬ 
лы, процессы, устройства ввода-вывода и прочее будут выглядеть как файлы или 
объекты, все они могут читаться при помощи всего одного системного вызова геасі. 
В противном случае пришлось бы иметь различные системные вызовы, такие как 
геасМл'Іе, геасі_ргос, геасПИу и т. д. 

В некоторых случаях может потребоваться несколько вариантов системных 
вызовов, но, как правило, на практике лучше иметь один системный вызов, обра¬ 
батывающий общий случай, с различными библиотечными процедурами, скрыва¬ 
ющими этот факт от программистов. Например, в операционной системе ІЖІХ 
есть системный вызов ехес для замены виртуального адресного пространства про¬ 
цесса. Наиболее общий вариант его использования выглядит следующим образом: 

ехес(паше. агдр. епѵр); 

Данный системный вызов загружает исполняемый файл пате и передает ему 
аргументы, на которые указывает аг§р, и список переменных окружения, на кото¬ 
рый указывает епѵр. Иногда бывает удобнее явно перечислить аргументы, поэто¬ 
му в библиотеках содержатся процедуры, вызываемые следующим образом: 

ехесКпаше. агдО. агді .агдп, 0): 

ехес1е(гше, агдО, агді .агдп. епѵр); 
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Эти процедуры всего лишь помещают аргументы в массив, после чего обраща¬ 
ются к системному вызову ехес, который и выполняет всю работу. Такая схема 
является лучшей в обоих смыслах: благодаря единственному простому системно¬ 
му вызову операционная система сохраняет свою простоту, в то же самое время 
программист получает возможность обращаться к системному вызову ехес различ¬ 
ными способами. 

Разумеется, пытаясь использовать один-единственный системный вызов для 
всех случаев жизни, легко дойти до крайностей. Для создания процесса в опера¬ 
ционной системе ІШІХ требуется два системных вызова: Гогк, за которым следует 
ехес. У первого вызова нет параметров; у второго вызова три параметра. Для срав¬ 
нения: у вызова ^іп32 АРІ для создания процесса, СгеаІеРгосе$$, 10 параметров, 
один из которых представляет собой указатель на структуру с дополнительными 
18 параметрами. 

Давным-давно следовало задать вопрос: «Произойдет ли катастрофа, если мы 
опустим что-нибудь из этого?» Правдивый ответ должен был звучать так: «В неко¬ 
торых случаях программист будет вынужден совершить больше работы для дос¬ 
тижения определенного эффекта, зато мы получим более простую, компактную 
и надежную операционную систему». Конечно, человек, предлагающий версию 
с этими 10 + 18 параметрами, мог добавить: «Но пользователи любят все эти 
возможности». Возразить на это можно было бы так: «Еще больше им нравятся 
системы, которые используют мало памяти и никогда не ломаются». Компромисс, 
заключающийся в большей функциональности за счет использования большего 
объема памяти, по крайне мере, виден невооруженным глазом и ему можно дать 
оценку (так как стоимость памяти известна). Однако трудно оценить количество 
дополнительных сбоев в год, которые появятся благодаря внедрению новой функ¬ 
ции. Кроме того, неизвестно, сделали бы пользователи тот же выбор, если им зара¬ 
нее была известна эта скрытая цена. Этот эффект можно резюмировать первым 
законом программного обеспечения Таненбаума: 

При увеличении размера программы количество содержащихся в ней ошибок 
также увеличивается. 

Когда к программе добавляются новые функции, при этом к ней добавляются 
новые процедуры, а вместе с ними и новые ошибки. Программисты, полагающие, 
что при добавлении новых функций к программе не добавится новых ошибок, либо 
являются новичками в программировании, либо верят, что за ними присматрива¬ 
ет добрая фея. 

Простота является не единственным принципом, которым следует руковод¬ 
ствоваться при разработке системных вызовов. Следует также помнить о фразе, 
сказанной Б. Лэмпсоном в 1984 году: 

Не скрывай мощь. 

Если у аппаратного обеспечения есть крайне эффективный способ выполнить 
что-либо, программистам следует предоставить простой доступ к этой возможнос¬ 
ти, а не хоронить ее внутри некой абстракции. Назначение абстракций заключается 
в том, чтобы скрывать нежелательные свойства, а не полезные свойства. Например, 
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предположим, что у аппаратуры есть специальный способ перемещения больших 
участков изображений по экрану (то есть в видеопамяти) на высокой скорости. 
В этом случае ввод нового системного вызова, предоставляющего доступ к этому 
механизму, будет оправдан, так как это лучше, чем читать данные из видеоОЗУ в 
обычную память, а затем писать эти данные обратно в видеоОЗУ. Новый вызов 
должен просто перемещать биты в видеопамяти. Если этот новый системный вы¬ 
зов будет быстрым, это позволит пользователям создавать более эффективные про¬ 
граммы. Если системный вызов медленный, никто не будет им пользоваться. 

При проектировании системы возникает также вопрос использования ориен¬ 
тированных на соединение вызовов или вызовов, не использующих соединений. 
Стандартные системные вызовы ІЖІХ и ^іп32 для чтения файлов являются ори¬ 
ентированными на соединение. Сначала вы открываете файл, затем читаете его и, 
наконец, закрываете файл. Некоторые протоколы работы с удаленными файлами 
также являются ориентированными на соединение. Например, чтобы использо¬ 
вать протокол РТР, пользователь сначала регистрируется на удаленной машине, 
читает файлы, а затем выходит из системы. 

С другой стороны, некоторые протоколы удаленного доступа к файлам не тре¬ 
буют соединений. Например, протокол ИР5 не требует соединений, как было по¬ 
казано в главе 10. Каждый вызов ИР5 является независимым, поэтому файлы не 
открываются до их чтения или записи. И, разумеется, файлы не нужно закрывать 
после чтения или записи. Всемирная паутина также не требует соединений: чтобы 
прочитать \ѵеЬ-страницу, вы просто запрашиваете ее. Не требуется никаких пред¬ 
варительных настроек (ТСР-соединение все-таки требуется, но оно представляет 
собой более низкий уровень протокола; протокол НТТР, используемый для дос¬ 
тупа к самой ѵ/еЬ-странице, не требует соединений). 

От того, какой из механизмов выбрать — ориентированный на соединение или 
не требующий соединений, — зависит, будет ли от механизма требоваться допол¬ 
нительная работа (например, по открытию файлов), или же эта работа переклады¬ 
вается на плечи использующей механизм прикладной программы. В последнем 
случае получается существенный выигрыш в эффективности, если к одному и тому 
же файлу программа обращается много раз. Для системы ввода-вывода на одной 
машине, где стоимость подготовки ввода-вывода (открытия файла) низка, вероят¬ 
но, лучше использовать стандартный способ (сначала открыть, затем использовать). 
Для удаленных файловых систем возможно использование обоих вариантов. 

Другой вопрос, возникающий при проектировании интерфейса системных вы¬ 
зовов, заключается в его открытости. Список системных вызовов, определяемых 
стандартом РОЗІХ, легко найти. Эти системные вызовы поддерживаются всеми 
системами ІЖІХ, как и небольшое количество других вызовов, но полный список 
всегда публикуется. Корпорация МісгозоЙ, напротив, никогда не публиковала спи¬ 
сок системных вызовов ^іпсіо^з 2000. Вместо этого публикуются функции ин¬ 
терфейса ^іп32 АРІ, а также вызовы других интерфейсов; эти списки содержат 
огромное количество библиотечных вызовов (более 13 000 в ^іпсіоѵ/з 2000), но 
только малое их число является настоящими системными вызовами. Аргумент 
в пользу открытости системных вызовов заключается в том, что программистам 
становится известна цена использования функций. Функции, исполняемые в про- 
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странстве пользователя, выполняются быстрее, чем те, которые требуют переклю¬ 
чения в режим ядра. Закрытость системных вызовов также имеет свои преимуще¬ 
ства, заключающиеся в том, что в результате достигается гибкость в реализации 
библиотечных процедур. То есть разработчики операционной системы получают 
возможность изменять действительные системные вызовы, сохраняя при этом 
работоспособность прикладных программ. 


Реализация 

Мы обсудили пользовательский интерфейс и интерфейс системных вызовов. 
Теперь пора обсудить вопрос реализации операционной системы. В следующих 
восьми разделах мы изучим некоторые общие концептуальные вопросы, относя¬ 
щиеся к стратегиям реализации. После этого мы рассмотрим некоторые примеры 
низкоуровневой техники, которая часто бывает полезной. 

Структура системы 

Вероятно, первым решением, которое должны принять разработчики системы, 
является решение о том, какой должна быть структура системы. Основные вари¬ 
анты мы изучили в разделе «Структура операционной системы» главы 1, но также 
рассмотрим их здесь. Монолитное неструктурированное устройство на самом деле 
представляет собой неудачную идею, подходящую разве что крошечной опера¬ 
ционной системе для, например, холодильника, но даже в этом случае ее исполь¬ 
зование спорно. 

Многоуровневые системы 

Разумный подход, установившийся с годами, заключается в создании многоуров¬ 
невых систем. Система ТНЕ, разработанная Э. Дейкстрой (см. табл. 1.3), была 
первой многоуровневой системой. У операционных систем ІЖІХ (см. рис. 10.2) 
и \УтсІо\ѵ5 2000 (см. рис. 11.2) также есть многоуровневая структура, но уровни 
в них в большей степени представляют собой способ описания системы, чем фак¬ 
тический руководящий принцип, использованный при ее построении. 

При создании новой системы разработчики должны сначала очень тщатель¬ 
но выбрать уровни и определить функциональность каждого уровня. Нижний 
уровень всегда должен пытаться скрыть самые неприятные особенности аппара¬ 
туры, как это делает уровень НАЬ на рис. 11.2. Вероятно, следующий уровень дол¬ 
жен обрабатывать прерывания, заниматься переключением контекста и работать 
с блоком управления памятью ММН, так что выше этого уровня код оказывается 
в основном машинно-независимым. На еще более высоких уровнях все зависит от 
вкусов и предпочтений разработчиков. Один вариант заключается в том, чтобы 
уровень 3 управлял потоками, включая планирование и синхронизацию потоков 
(рис. 12.1). При этом, начиная с уровня 4, мы получаем правильные потоки, кото¬ 
рые нормально планируются и синхронизируются при помощи стандартного меха¬ 
низма (например, мьютексов). 
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Уровень 

7 
6 
5 
4 
3 
2 
1 

Рис. 12.1. Одна из возможных структур современной многоуровневой операционной системы 

На уровне 4 мы обнаружим драйверы устройств, каждый из которых работает 
как отдельный поток, со своим состоянием, счетчиком команд, регистрами и т. д„ 
возможно (но не обязательно), в адресном пространстве ядра. Такое устройство 
может существенно упростить структуру ввода-вывода, потому что когда воз¬ 
никает прерывание, оно может быть преобразовано в системный вызов ипіоск на 
мьютексе и обращение к планировщику, чтобы (потенциально) запустить новый 
готовый поток, который был блокирован мьютексом. Этот подход используется 
в системе МШІХ, но в операционных системах ІЖІХ, Ьіпих и ^іпсіоѵѵз 2000 об¬ 
работчики прерываний реализованы как независимая часть системы, а не потоки, 
которые сами могут управляться планировщиком, приостанавливаться и т. д. 
Поскольку основная сложность любой операционной системы заключается во 
вводе-выводе, заслуживает внимания любой способ сделать его более удобным для 
обработки и более инкапсулированным. 

Над уровнем 4, скорее всего, мы обнаружим виртуальную память, одну или не¬ 
сколько файловых систем и обработчики системных вызовов. Если виртуальная 
память расположена на более низком уровне, чем файловые системы, тогда блоч¬ 
ный кэш может быть выгружаемым, что позволяет менеджеру виртуальной памя¬ 
ти динамически определять, как следует распределять физическую память между 
страницами пользователей и страницами ядра, включая кэш. Подобным образом 
работает операционная система ^іпсіо\ѵ5 2000. 

Экзоядра 

Хотя у многоуровневых структур есть много сторонников среди разработчиков 
систем, существует также другой лагерь, придерживающийся точно противопо¬ 
ложной точки зрения [111]. Их точка зрения базируется на сквозном аргументе 
[286]. Эта концепция заключается в том, что если что-либо должно быть выпол¬ 
нено самой пользовательской программой, то неэффективно выполнять это также 
и на нижнем уровне. 

Рассмотрим применение этого принципа к удаленному доступу к файлам. Если 
система заботится о том, чтобы файлы не были повреждены, она должна считать 
для каждого записываемого файла контрольную сумму и хранить ее вместе с фай¬ 
лом. Когда файл пересылается по сети, вместе с файлом пересылается также его 
контрольная сумма, которая проверяется по получении файла принимающей сто¬ 
роной. Если контрольные суммы не совпадают, файл пересылается снова. 


Обработчик системных вызовов 


Файловая система 1 


Файловая система т 


Виртуальная память 


Драйвер 1 Драйвер 2 


Драйвер п 


Потоки, планирование потоков, синхронизация потоков 


Обработка прерываний, переключение контекста, ММЫ 
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Проверка контрольной суммы является более аккуратным методом, чем ис¬ 
пользование надежной сети. Она позволяет, помимо ошибок, возникающих при 
передаче файла по сети, перехватывать также ошибки чтения или записи на диск, 
ошибки памяти, программные ошибки в маршрутизаторах и т. д. Сквозной аргу¬ 
мент утверждает, что при этом использование надежной сети перестает быть не¬ 
обходимым, так как в конечной точке (у получающего процесса) есть достаточно 
информации, чтобы проверить правильность полученного файла самостоятельно. 
Единственный довод в пользу использования в данном случае надежного сетево¬ 
го протокола заключается в повышении эффективности обработки сетевых оши¬ 
бок на более низком уровне. 

Сквозной аргумент может быть расширен почти до пределов всей операцион¬ 
ной системы. Он утверждает, что операционная система не должна делать того, что 
пользовательская программа может сделать сама. Например, зачем нужна файло¬ 
вая система? Почему бы не позволить пользователю просто читать и писать участ¬ 
ки диска защищенным способом? Конечно, большинству пользователей нравится 
работать с файлами, но, согласно сквозному аргументу, файловая система должна 
быть библиотечной процедурой, которую можно скомпоновать с любой программой, 
нуждающейся в файлах. Этот подход позволяет различным программам использо¬ 
вать различные файловые системы. Такая цепь рассуждений приводит к выводу, 
что операционная система должна только обеспечивать безопасное распределение 
ресурсов (например, процессорного времени или дисков) среди соревнующихся 
за них пользователей. Экзоядро представляет собой операционную систему, по¬ 
строенную в соответствии со сквозным аргументом [111]. 

Системы клиент-сервер 

Компромиссом между операционной системой, которая делает все, и операцион¬ 
ной системой, не делающей ничего, является операционная система, делающая 
кое-что. Результатом такого дизайна является схема микроядра, при которой 
большая часть операционной системы представляет собой серверные процессы, ра¬ 
ботающие на уровне пользователя (см. рис. 1.23). Такое устройство обладает наи¬ 
большей модульностью и гибкостью по сравнению с другими схемами. Предел гиб¬ 
кости заключается в том, чтобы каждый драйвер устройства также работал в виде 
пользовательского процесса, полностью защищенного от ядра и других драйверов. 
Удаление драйверов из ядра позволяет устранить наибольший источник неста¬ 
бильности в любой операционной системе — полные ошибок драйверы, написан¬ 
ные третьими фирмами. 

Разумеется, драйверы устройств должны получать доступ к аппаратным реги¬ 
страм устройств, поэтому необходим определенный механизм, обеспечивающий 
этот доступ. Если аппаратура это позволяет, то каждому драйверному процессу 
может быть предоставлен доступ только к нужным ему устройствам ввода-выво¬ 
да. Например, если регистры устройств ввода-вывода отображаются на адресное 
пространство памяти, то у каждого драйверного процесса может быть страница 
памяти, на которую отображаются регистры соответствующего устройства, но не 
другие страницы. Если же пространство портов ввода-вывода частично защище¬ 
но, каждому драйверу может быть разрешен доступ к нужной ему порции этого 
пространства. 
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Даже если аппаратная поддержка недоступна, этой идеей все равно можно вос¬ 
пользоваться. Для этого нужен новый системный вызов, доступный только для 
драйверных процессов. Для работы этот системный вызов пользуется списком пар 
(порт, значение). Ядро сначала проверяет, владеет ли процесс всеми портами в 
списке. Если да, то оно копирует в порты соответствующие значения для инициа¬ 
лизации устройства ввода-вывода. Подобный системный вызов может быть ис¬ 
пользован для чтения портов ввода-вывода защищенным образом. 

Такой метод защищает структуры данных ядра от изучения и повреждения их 
драйверами устройств, что (по большей части) хорошо. Возможно создание ана¬ 
логичного набора вызовов, позволяющим драйверам устройств читать и писать 
таблицы ядра, но только под контролем ядра и с его одобрения. 

Главная проблема такого подхода, и проблема микроядер вообще, заключается 
в снижении производительности, вызываемом дополнительными переключени¬ 
ями контекста. Однако практически вся работа по созданию микроядер была 
выполнена много лет назад, когда центральные процессоры были значительно мед¬ 
леннее. Сегодня не так уж много приложений, использующих каждую каплю мощ¬ 
ности процессора, которые не могут смириться с малейшей потерей производи¬ 
тельности. В конце концов, когда работает текстовый редактор или \ѵеЪ-браузер, 
центральный процессор простаивает около 90 % времени. Если операционная сис¬ 
тема, основанная на микроядре, превращает систему с процессором, работающем 
на частоте 900 МГц, в надежную систему, аналогичную по производительнос¬ 
ти системе с частотой 800 МГц, мало кто из пользователей станет жаловаться. 
Большинство пользователей были просто счастливы всего несколько лет назад, 
когда приобрели свой предыдущий компьютер с потрясающей тогда частотой про¬ 
цессора в 100 МГц. 

Расширяемые системы 

В обсуждавшихся выше системах клиент-сервер идея заключалась в том, чтобы 
вынести за пределы ядра столько, сколько возможно. Противоположный подход 
заключается в том, чтобы поместить больше модулей в ядро, но защищенным спо¬ 
собом. Ключевое слово здесь, разумеется, «защищенным». Некоторые механизмы 
защиты, изучавшиеся в разделе «Мобильные программы» главы 9, предназнача¬ 
лись для импортирования апплетов по Интернету, но они в той же мере примени¬ 
мы для установки чужеродного кода в ядро. Самыми важными из них являются 
«песочницы» и программы с электронной подписью, так как интерпретацию при¬ 
менять в ядре непрактично. 

Конечно, сама расширяемая система не является методом структурирования 
операционной системы. Однако, начав с минимальной системы, состоящей в основ¬ 
ном из механизма защиты, и постепенно добавляя к ядру защищенные модули, 
пока не будет достигнута требуемая функциональность, можно создать минималь¬ 
ную систему для конкретного приложения. При таком подходе новая операционная 
система может выкраиваться под каждое новое приложение благодаря включению 
только тех элементов, которые необходимы для данного приложения. Примером 
такой системы является Рагатесіит [336]. 
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Потоки ядра 

Еще один вопрос, имеющий отношение к данной теме, независимо от выбора струк¬ 
турной модели — это системные потоки. Иногда бывает удобно позволить суще¬ 
ствовать потокам ядра отдельно от пользовательских процессов. Эти потоки мо¬ 
гут работать в фоновом режиме, записывая «грязные» страницы на диск, занимаясь 
свопингом процессов и т. д. На самом деле ядро само может целиком состоять из 
таких потоков. Когда пользователь обращается к системному вызову, пользова¬ 
тельский поток не выполняется в режиме ядра, а блокируется и передает управле¬ 
ние потоку ядра, который принимает управление для выполнения работы. 

Помимо потоков ядра, работающих в фоновом режиме, большинство систем 
также запускают в фоновом режиме множество процессов-демонов. Хотя они и не 
являются частью операционной системы, они часто выполняют «системные» функ¬ 
ции. Это может быть получение и отправка электронной почты, а также обслужи¬ 
вание различных запросов удаленных пользователей, как, например, РТР или \ѵеЬ- 
страницы. 

Механизм и политика 

Еще один принцип, помогающий добиться архитектурной согласованности, наря¬ 
ду с принципами минимализма и структурированности заключается в отделении 
механизма от политики. Если поместить механизм в операционную систему, а по¬ 
литику оставить пользовательским процессам, система может остаться неизмен¬ 
ной, даже если появляется потребность в изменении политики. Даже если модуль, 
занимающийся политикой, должен располагаться в ядре, он должен быть, по воз¬ 
можности, изолирован от механизма, чтобы изменения в модуле политики не вли¬ 
яли на модуль механизма. 

Чтобы сделать границу между механизмом и политикой отчетливей, рассмот¬ 
рим два примера из реального мира. В качестве первого примера возьмем боль¬ 
шую компанию, у которой есть отдел заработной платы, ответственный за выпла¬ 
ту жалования сотрудникам. У него есть компьютеры, программное обеспечение, 
бланки, договоренность с банками, а также другие механизмы, требуемые для фак¬ 
тической выплаты зарплаты. Однако политика — принятие решений, кто и сколь¬ 
ко получит — полностью отделена и является прерогативой управления. Отдел 
заработной платы просто выполняет порученную ему работу. 

В качестве второго примера рассмотрим ресторан. Он обладает механизмом для 
обслуживания посетителей, включая столы, посуду, официантов, полную обору¬ 
дования кухню, договоры с компаниями, продающими товары по кредитным кар¬ 
точкам и т. д. Политика, то есть что будет в меню, определяется шеф-поваром. Если 
шеф-повар решит, что тофу кончился, а большие бифштексы остались, то новая 
политика может быть выполнена существующим механизмом. 

Теперь рассмотрим некоторые примеры из области операционных систем. 
Во-первых, взглянем на планирование потоков. В ядре может располагаться при¬ 
оритетный планировщик с к уровнями приоритетов. Этот механизм представляет 
собой массив, проиндексированный уровнем приоритета, как показано на рис. 10.4 
или на рис. 11.8. Каждый элемент массива представляет собой заголовок списка 
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готовых потоков с данным уровнем приоритета. Планировщик просто просматри¬ 
вает массив, начиная с максимального приоритета, выбирая первый подходящий 
поток. Политика заключается в установке приоритетов. В системе могут быть раз¬ 
личные классы пользователей, например, у каждого пользователя может быть свой 
приоритет. Система может также позволять процессам устанавливать относи¬ 
тельные приоритеты для своих потоков. Приоритеты могут увеличиваться после 
завершения операции ввода-вывода или уменьшаться, когда процесс истратил от¬ 
пущенный ему квант. Может применяться также еще множество других полити¬ 
ческих подходов, но основной принцип состоит в разделении между установкой 
политики и претворением ее в жизнь. 

Вторым примером является страничная подкачка. Механизм включает в себя 
управление блоком ММІІ, поддержку списка занятых и свободных страниц, а так¬ 
же программу для перемещения страниц с диска в память и обратно. Политика 
в данном случае заключается в принятии решения о выполняемых действиях при 
возникновении страничного прерывания. Политика может быть локальной или 
глобальной, основываться на алгоритме ЫШ, РІРО или каком-либо другом алго¬ 
ритме, но она может (и должна) быть полностью отделена от механики фактичес¬ 
кой работы со страницами. 

Третий пример — возможность загрузки модулей в ядро. Механизм определя¬ 
ет то, как они устанавливаются в ядро, как они связываются, к каким вызовам они 
могут обращаться и какие вызовы могут сами предоставлять. Политика определя¬ 
ет список пользователей, которым разрешается загружать модуль в ядро, а также 
список модулей, которые разрешается загружать каждому пользователю. Возмож¬ 
но, только суперпользователь может загружать модули, но разрешение загружать 
модули может также предоставляться и любому пользователю, если у модуля есть 
цифровая подпись соответствующей авторитетной организации. 

Ортогональность 

Хорошая системная организация включает в себя отдельные концепции, которые 
можно независимо смешивать. Например, в языке С есть примитивные типы дан¬ 
ных, включающие целые, символьные числа и числа с плавающей точкой. Существу¬ 
ют механизмы для комбинирования типов данных, включая массивы, структуры 
и объединения. Эти концепции независимы друг от друга, что позволяет создавать 
целые массивы, символьные массивы, массивы структур, структуры, состоящие из 
массивов и т. д. Действительно, как только определен новый тип данных, напри¬ 
мер массив целых чисел, он может использоваться в качестве члена структуры или 
объединения, как если бы он был примитивным типом данных. Возможность не¬ 
зависимо комбинировать раздельные концепции называется ортогональностью. 
Это свойство является прямым следствием простоты и полноты принципов. 

Понятие ортогональности также встречается в операционных системах в раз¬ 
личных формах. Одним из примеров является системный вызов сіопе операцион¬ 
ной системы Ілпих, создающий новый поток. В качестве параметра этот вызов при¬ 
нимает битовый массив, задающий такие режимы, как независимое друг от друга 
совместное использование или копирование адресного пространства, рабочего 
каталога, дескрипторов файлов и сигналов. Если копируется все, то мы получаем 
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новый процесс, как и при использовании системного вызова йэгк. Если ничего не 
копируется, это означает, что создается новый поток в текущем процессе. Однако 
вероятно и создание промежуточных форм, невозможных в традиционных систе¬ 
мах ІЖІХ. Разделение свойств и их ортогональность позволяет получить более 
детальную степень управления. 

Другое применение ортогональности — разделение понятий процесса и потока 
в \Ѵіпс1о\Ѵ5 2000. Процесс представляет собой контейнер для ресурсов, не более 
и не менее. Поток представляет собой объект планирования. Когда один процесс 
получает дескриптор от другого процесса, не имеет значения, сколько потоков 
у него есть. Когда планировщик выбирает поток, не важно, какому процессу он 
принадлежит. Эти понятия ортогональны. 

Наш последний пример ортогональности возьмем из операционной системы 
ШІХ. Создание процесса происходит здесь в два этапа: при помощи системных 
вызовов Іюгк и ехес. Создание нового адресного пространства и заполнение его 
новым образом памяти в данном случае разделены, что позволяет выполнить опре¬ 
деленные действия между этими этапами. В операционной системе \Ушс1оѵѵ5 2000 
эти два этапа нельзя разделить, то есть концепции создания нового адресного про¬ 
странства и его заполнения новым образом памяти не являются ортогональными 
в этой системе. Последовательность системных вызовов сіопе и ехес в системе 
Ьіпих является еще более ортогональной, так как в данном случае возможно еще 
более детальное управление этими действиями. Общее правило может быть сфор¬ 
мулировано следующим образом: наличие небольшого количества ортогональных 
элементов, которые могут комбинироваться различными способами, позволяет 
создать небольшую простую и элегантную систему. 


Именование 

У большинства долгоживущих структур данных, используемых операционной 
системой, есть имя или идентификатор, по которому к ним можно обращаться. 
Среди очевидных примеров можно назвать регистрационные имена, имена фай¬ 
лов, устройств, идентификаторов процессов и т. д. Способ создания и использова¬ 
ния этих имен представляет собой важный вопрос при проектировании и реализа¬ 
ции системы. 

Имена, создаваемые для использования их людьми, представляют собой сим¬ 
вольные строки формата А5СІІ или Ипісосіе и, как правило, являются иерархи¬ 
ческими. Так, иерархия отчетливо видна на примере путей файлов, например, путь 
/и$г / а$С/Ьоок5/то$2/сНар-12 состоит из имен каталогов, поиск которых следует 
начинать в корневом каталоге. Адреса ІШЬ также являются иерархическими. Напри¬ 
мер, ІШЬ ѵѵѵѵѵѵ.С5.ѵи.пІ/~а5Ѵ указывает на определенную машину (тш) определен¬ 
ного факультета (сз) определенного университета (ѵи) определенной страны ( пі ). 
Участок ІШЬ после косой черты обозначает определенный файл на указанной 
машине, в данном случае по умолчанию это файл тітіті/іпйехЫтІ в домашнем ка¬ 
талоге пользователя азі. Обратите внимание, что ІШЬ (а также адреса БИЗ во¬ 
обще, включая адреса электронной почты) пишутся «задом наперед», начинаясь 
с нижнего уровня дерева, в отличие от имен файлов, начинающихся с вершины 
дерева. На это можно взглянуть и по-другому, если положить дерево горизонталь- 
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но. При этом в одном случае дерево будет начинаться слева и расти направо, а в 
другом случае, наоборот, будет начинаться справа и расти влево. 

Часто используется двухуровневое именование: внешнее и внутреннее. Напри¬ 
мер, к файлам всегда можно обратиться по имени, представляющему собой символь¬ 
ную строку. Кроме этого, почти всегда существует внутреннее имя, используемое 
системой. В операционной системе ІЖІХ реальным именем файла является номер 
его і-узла. Имя в формате А5СІІ вообще не используется внутри системы. В дей¬ 
ствительности это имя даже не является уникальным, так как на файл может 
указывать несколько ссылок. А в операционной системе \Утс1о\ѵ$ 2000 в качестве 
внутреннего имени используется индекс файла в таблице МРТ. Работа каталога за¬ 
ключается в преобразовании внешних имен во внутренние, как показано на рис. 12.2. 


Внешнее имя: /изг/а5І/Ьоокз/то52/СІпар-12 





Внутреннее имя: 2 


Рис. 12.2. Каталоги используются для преобразования внешних имен во внутренние 


Во многих случаях (таких как приведенный выше пример с именем файла) 
внутреннее имя файла представляет собой уникальное целое число, служащее 
индексом в таблице ядра. Другие примеры имен-индексов: дескрипторы файлов 
в системе ІШІХ и дескрипторы объектов в \Ѵіпс1о\ѵ$ 2000. Обратите внимание, что 
ни у одного из данных примеров имен нет внешнего представления. Они предна¬ 
значены исключительно для внутреннего использования системой и работающи¬ 
ми процессами. В целом использование для временных имен табличных индексов, 
не сохраняющихся после перезагрузки системы, является удачным замыслом. 

Операционные системы часто поддерживают несколько пространств имен, как 
внешних, так и внутренних. Например, в главе 11 мы рассмотрели три внешних 
пространства имен, поддерживаемых операционной системой \У1пс1о\ѵ$ 2000: име¬ 
на файлов, имена объектов и регистрационные имена (существует также простран¬ 
ство имен Асііѵе Оігесіогу, которое мы не обсуждали). Кроме того, существует 
бесчисленное количество внутренних пространств имен, для которых использу¬ 
ются целые числа без знака — дескрипторы объектов, записи таблицы МРТ и т. д. 
Хотя имена во внешних пространствах имен представляют собой строки формата 
Ііпісосіе, поиск файла по имени в реестре не будет работать, как не будет работать 
и попытка использования индекса МРТ в таблице объектов. В правильно спроек¬ 
тированной операционной системе обязательно уделяется определенное внимание 
тому, сколько требуется пространств имен, какой синтаксис используется в каждом 
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из них, как можно отличить одно от другого, существуют ли абсолютные и отно¬ 
сительные имена и т. д. 

Время связывания 

Как мы видели, для обращения к объектам в операционных системах используются 
различные типы имен. Иногда преобразование имени в объект является фиксиро¬ 
ванным, а иногда нет. В последнем случае может быть важным, когда имя связы¬ 
вается с объектом. Вообще говоря, раннее связывание проще, но не обладает гиб¬ 
костью, тогда как позднее связывание сложнее, зато часто является более гибким. 

Чтобы внести ясность в понятие времени связывания, давайте рассмотрим не¬ 
которые примеры из реального мира. Примером раннего связывания может быть 
практика некоторых колледжей, позволяющих родителям зачислять своего ребен¬ 
ка в колледж с момента рождения и вносить плату за его обучение заранее. Когда 
спустя 18 лет студент приходит в колледж, его обучение уже полностью оплачено, 
независимо от стоимости обучения на данный момент. 

В промышленности ранним связыванием является заказ деталей заранее. Напро¬ 
тив, производство продукта точно в срок требует от поставщиков способности пре¬ 
доставлять требуемые детали прямо на месте, без предварительного заказа. Такая 
схема представляет собой пример позднего связывания. 

Языками программирования часто поддерживаются различные виды связывания 
для переменных. Глобальные переменные связывает с конкретным виртуальным 
адресом компилятор. Это пример раннего связывания. Локальным переменным 
процедуры виртуальные адреса назначаются (в стеке) во время выполнения проце¬ 
дуры. Это пример промежуточного связывания. Переменным, хранящимся в куче 
(память для которых выделяется при помощи процедуры таііос в программах на 
языке С или процедуры пет в программах на языке ^ѵа), виртуальный адрес на¬ 
значается только на время их фактического использования. Это пример позднего 
связывания. 

Для большей части структур данных в операционных системах чаще применяет¬ 
ся раннее связывание, но иногда для гибкости используется позднее связывание. 
К этому вопросу имеет отношение выделение памяти. В ранних многозадачных 
системах из-за отсутствия аппаратной перенастройки адресов программу прихо¬ 
дилось загружать по определенному адресу памяти и настраивать ее на работу по 
этому адресу. Если эта программа когда-либо выгружалась на диск, ее нужно было 
потом загрузить в те же адреса памяти, в противном случае она не могла работать. 
Напротив, виртуальная память с постраничной подкачкой представляет собой при¬ 
мер позднего связывания. Фактический физический адрес, соответствующий дан¬ 
ному виртуальному адресу, неизвестен до тех пор, пока страница не будет физи¬ 
чески перенесена в память. 

Другим примером позднего связывания является размещение окна в графичес¬ 
ком интерфейсе пользователя. В отличие от старых графических систем, в кото¬ 
рых программист должен был указывать абсолютные экранные координаты для 
всех изображений, в современных графических интерфейсах пользователя про¬ 
граммное обеспечение использует координаты относительно исходного окна. Такие 
координаты неизвестны до тех пор, пока это окно не будет выведено на экран, и даже 
могут быть со временем изменены. 
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Статические и динамические структуры 

Разработчики операционных систем постоянно вынуждены выбирать между ста¬ 
тическими и динамическими структурами данных. Статические структуры всегда 
проще для понимания, легче для программирования и быстрее в использовании. 
Динамические структуры обладают большей гибкостью. Очевидный пример — 
таблица процессов. В ранних системах для каждого процесса просто выделялся 
фиксированный массив структур. Если таблица процесса состояла из 256 элемен¬ 
тов, тогда в любой момент могло существовать не более 256 процессов. Попытка 
создания 257-го процесса заканчивалась неудачей по причине отсутствия места 
в таблице. Аналогичные соображения были справедливы для таблицы открытых 
файлов (как для каждого пользователя в отдельности, так и для системы в целом) 
и различных других таблиц ядра. 

Альтернативная стратегия заключается в создании таблицы процессов в виде 
связного списка мини-таблиц, начиная с одной-единственной мини-таблицы. Ког¬ 
да эта таблица заполняется, в глобальном пуле выделяется память под следующую 
таблицу, которая связывается с первой таблицей. Таким образом, таблица процес¬ 
са не переполнится, пока не закончится вся память у ядра. 

С другой стороны, использование связных списков приводит к усложнению 
программы поиска записей в таблице. Например, программа для поиска иденти¬ 
фикатора процесса рМ в статической таблице процессов показана в листинге 12.2. 
Эта программа проста и эффективна. Чтобы выполнить ту же задачу для связного 
списка мини-таблиц, потребуется больше работы. 

Листинг 12.2. Программа для поиска в таблице идентификатора процесса 

Гоипсі = 0; 

Гог (р - &ргос_ГаЫе[0]; р < &ргос_1:аЫе[РК0С_ТАВЦЕ_5І2Е] : р++) { 
іГ (р->ргос_ріс) == рШ) { 

Гоипс) = 1; 

Ьгеак: 


Статические таблицы лучше всего использовать, когда имеется много памяти 
или когда заранее можно довольно точно предсказать размер таблицы. Например, 
в однопользовательской системе маловероятно, что пользователь запустит одно¬ 
временно более 32 процессов, и поэтому не случится катастрофы, если пользова¬ 
телю будет отказано в запуске 33-го процесса. 

Альтернативный метод заключается в использовании таблицы фиксированного 
размера, но с выделением, когда эта таблица заполнится, новой таблицы фиксиро¬ 
ванного размера, например, в два раза большей. При этом текущие записи копиру¬ 
ются из старой таблицы в новую, а память, которая была занята старой таблицей, 
возвращается в пул. Таким образом, таблица всегда остается непрерывной, а не связ¬ 
ной. Недостаток этого подхода состоит в том, что требуется определенное управ¬ 
ление памятью, кроме того, адрес таблицы будет переменным вместо константы. 

То же самое относится к стекам ядра. Когда поток переключается в режим ядра 
или когда запускается поток в режиме ядра, этому потоку требуется стек в адрес- 
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ном пространстве ядра. Для потоков пользователя стек можно инициализировать 
так, чтобы он рос вниз от вершины виртуального адресного пространства. При этом 
его размер можно заранее не указывать. Для потоков ядра размер стека должен 
быть указан заранее, так как стек занимает часть виртуального адресного простран¬ 
ства ядра, кроме того, стеков может быть несколько. Вопрос заключается в следу¬ 
ющем: сколько памяти следует выделить для каждого стека? Преимущества и не¬ 
достатки различных подходов здесь примерно такие же, как и в случае с таблицей 
процессов. 

Проблема выбора между статическим или динамическим выделением памяти 
возникает также для планирования процессов. В некоторых системах, особенно 
системах реального времени, планирование может быть выполнено заранее стати¬ 
чески. Например, авиалинии знают, в котором часу их самолеты будут взлетать, за 
несколько недель до их фактического отправления. Подобно этому, мультимедий¬ 
ным системам известно заранее, когда запускать те или иные видео-, аудио- и дру¬ 
гие процессы. Для универсальных систем общего назначения эти соображения не 
работают, и планирование должно быть динамическим. 

Вопрос выбора между статическим или динамическим выделением памяти воз¬ 
никает и при проектировании структур ядра. Значительно проще, если ядро по¬ 
строено, как единая двоичная программа, загружаемая в память для работы. След¬ 
ствием такого подхода, однако, является то, что для установки каждого нового 
устройства ввода-вывода необходима перекомпоновка ядра вместе с драйвером 
нового устройства. Подобным образом работали ранние версии операционной сис¬ 
темы ІЛѴІХ, что всех устраивало, так как новые устройства ввода-вывода добавля¬ 
лись к мини-компьютерам довольно редко. Сегодня большинство операционных 
систем позволяют динамически добавлять программы в ядро, со всеми дополни¬ 
тельными сложностями, которые такой подход влечет за собой. 


Реализация системы сверху вниз и снизу вверх 

Хотя лучше всего проектировать систему сверху вниз, теоретически реализация 
системы может выполняться как сверху вниз, так и снизу вверх. При реализации 
сверху вниз конструкторы начинают с обработчиков системных вызовов, а затем 
смотрят, какие механизмы и структуры данных требуются для их поддержки. Затем 
пишутся эти процедуры, при этом весь процесс повторяется до тех пор, пока не 
будет достигнут аппаратный уровень. 

Недостаток этого подхода заключается в том, что, пока в наличии имеются толь¬ 
ко процедуры верхнего уровня, трудно что-либо протестировать. По этой причине 
многие разработчики считают более практичным построение системы снизу вверх. 
При таком подходе сначала пишется программа, скрывающая аппаратуру нижне¬ 
го уровня (уровень Н АЬ на рис. 11.2). Обработка прерываний и драйвер часов так¬ 
же оказываются нужны уже на раннем этапе конструирования. 

Затем можно реализовать многозадачность вместе с простым планировщиком 
(например, запускающим процессы в порядке циклической очереди). Уже в этот 
момент система может быть протестирована, чтобы проверить, правильно ли она 
управляет несколькими процессами. Если все работает нормально, можно присту- 
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пить к детальной разработке различных таблиц и структур данных, необходимых 
системе, особенно тех, которые управляют процессами и потоками, а также памя¬ 
тью. Ввод-вывод и файловую систему можно отложить на потом, реализовав пона¬ 
чалу лишь примитивный ввод с клавиатуры и вывод на экран для тестирования и 
отладки. В некоторых случаях следует защитить ключевые низкоуровневые струк¬ 
туры данных, разрешив доступ к ним только с помощью специальных процедур 
доступа — в результате мы получаем объектно-ориентированное программирова¬ 
ние, независимо от того, какой язык программирования применяется в действи¬ 
тельности. Когда нижние уровни созданы, они могут быть тщательно протестиро¬ 
ваны. Таким образом, система создается снизу вверх, подобно тому, как строятся 
высокие здания. 

Если над проектом работает большая команда программистов, тогда альтерна¬ 
тивный подход заключается в том, чтобы сначала создать детальный проект всей 
системы, после чего распределить задачи по написанию отдельных модулей среди 
различных групп программистов. Каждая группа независимо тестирует собствен¬ 
ную работу. Когда все модули готовы, они объединяются и тестируются совмест¬ 
но. Недостаток такого подхода заключается в том, что если изначально ничто не 
работает, очень трудно определить, который модуль создан правильно, а какой со¬ 
держит ошибки и какая группа программистов неверно поняла, чего ей следует 
ожидать от других модулей. Тем не менее такой метод часто применяется при на¬ 
личии большого количества программистов, чтобы максимально использовать рас¬ 
параллеливание работ по конструированию системы. 

Полезные методы 

Итак, мы только что обсудили некоторые абстрактные идеи, применяющиеся при 
проектировании и конструировании операционных систем. Теперь мы рассмотрим 
несколько конкретных методов, полезных при реализации систем. Разумеется, 
существует также множество других методов, но объем книги не позволяет нам 
рассмотреть все методы. 

Сокрытие аппаратуры 

Большое количество аппаратуры весьма неудобно в использовании. Его следует 
скрывать на ранней стадии реализации системы (если только оно не предоставля¬ 
ет особых возможностей). Некоторые детали самого нижнего уровня могут быть 
скрыты уровнем вроде НАЬ, показанным на рис. 12.1. Однако есть детали, кото¬ 
рые таким способом скрыть невозможно. 

На ранней стадии конструирования системы следует решить вопрос обра¬ 
ботки прерываний. Наличие прерываний делает программирование неприят¬ 
ным делом, но операционные системы должны работать с прерываниями. Один 
из подходов состоит в том, чтобы немедленно преобразовать их во что-либо иное. 
Например, каждое прерывание можно превратить в появляющийся новый по¬ 
ток. При этом более высокие уровни будут иметь дело уже не с прерываниями, 
а с потоками. 
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Второй метод заключается в том, чтобы преобразовать каждое прерывание 
в операцию ипіоск на мьютексе, которого ожидает соответствующий драйвер. Тог¬ 
да единственный эффект от прерывания будет заключаться в том, что один из по¬ 
токов перейдет в состояние готовности. 

Третий подход состоит в преобразовании прерывания в сообщение какому- 
либо потоку. Программа низкого уровня просто формирует сообщение, в котором 
содержатся сведения о том, откуда прибыло прерывание, ставит его в очередь 
и вызывает планировщик, который, возможно, запустит процесс, вероятно, ожида¬ 
ющий этого сообщения. Все эти методы, а также подобные им другие, пытаются 
преобразовать прерывания в операции синхронизации потоков. Обработкой каж¬ 
дого прерывания соответствующим потоком в соответствующем контексте проще 
управлять, чем создать обработчик прерываний, работающий в произвольном 
контексте, то есть в том, в котором случилось прерывание. Разумеется, обработка 
прерываний должна быть эффективной, но глубоко внутри операционной систе¬ 
мы эффективным должно быть все. 

Большинство операционных систем спроектировано так, чтобы работать на 
различных платформах. Эти платформы могут отличаться центральными про¬ 
цессорами, блоками МІѴШ, длиной машинного слова, объемом оперативной па¬ 
мяти и другими параметрами, которые трудно замаскировать уровнем НАЬ или 
его эквивалентом. Тем не менее желательно иметь единый набор исходных фай¬ 
лов, используемых для формирования всех версий. В противном случае каждую 
обнаруженную ошибку придется исправлять много раз во многих исходных фай¬ 
лах. При этом возникает опасность, что исходные файлы будут отличаться друг от 
друга все больше и больше. 

С некоторыми различиями аппаратуры, такими как объем ОЗУ, можно бороть¬ 
ся, оформив этот параметр в виде переменной и определяя его значение во время 
загрузки системы. Например, переменная, содержащая объем оперативной памя¬ 
ти, может использоваться программой, предоставляющей память процессам, а так¬ 
же для определения размера блока кэша, таблиц страниц и т. д. Даже размер 
статических таблиц, таких как таблица процессов, может задаваться при загрузке, 
в зависимости от общего объема оперативной памяти. 

Однако другие различия, такие как различия в центральных процессорах, не 
могут быть скрыты при помощи единого двоичного кода, определяющего при за¬ 
грузке тип процессора. Один из способов решения данной проблемы состоит в ис¬ 
пользовании условной трансляции единого исходного кода. В исходных файлах 
для различных конфигураций используются определенные флаги компиляции, 
позволяющие получать из единого исходного текста различные двоичные фай¬ 
лы в зависимости от центрального процессора, длины слова, блока МІѴГО ит. д. 
Представьте себе операционную систему, которая должна работать на компью¬ 
терах с процессорами Репіішп и іЛігаЗРАКС, требующих различных программ 
инициализации. Процедура іпіі может быть написана так, как показано в лис¬ 
тинге 12.3, а. В зависимости от значения константы СРІІ, определяемой в заголо¬ 
вочном файле соп/і§.Н, будет выполняться либо один тип инициализации, либо 
другой. Поскольку в двоичном файле содержится только один вариант програм¬ 
мы, потери эффективности не происходит. 
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Листинг 12.3. Условная компиляция, зависящая от типа центрального 

процессора (а); условная компиляция, зависящая от длины слова (б) 


Цпсіисіе "сопГід.Іі" 
іпШ ) 

{ 

#іг (сри — релтшм) 

/* Здесь инициализация для РепЕіит */ 
#епсІіГ 

#і г (сри == ілтказрако 

/* Здесь инициализация для ІПТгаЗРАКС */ 
#епсМГ 


#1 псіибе "сопГід.Ь" 

#ІГ (ШИМ.Е№ТН == 32) 
ІуресІеЕ іпі Кедізіег; 
#епсІі Г 

#ІГ Ш0ИП.Е№ТН == 64) 
ІуресІеЕ Іопд Кедізіег; 
#епсІі Е 

Кедізіег КО. К1. К2. КЗ: 


а б 

В качестве второго примера предположим, что нам требуется тип данных Ке§Ыег, 
который должен состоять из 32 бит на компьютере с процессором РепЕіит н 64 бит 
на компьютере с процессором іЛігаЗРАКС. Этого можно добиться при помощи 
условного кода в листинге 12.3, б (при условии, что компилятор воспринимает тип 
іпС, как 32-разрядное целое, а тип 1оп§ — как 64-разрядное). Как только это опреде¬ 
ление дано (возможно, в заголовочном файле, включаемом во все остальные исход¬ 
ные файлы), программист может просто объявить переменные типа Ке§Ыег и быть 
уверенным, что эти переменные имеют правильный размер. 

Разумеется, заголовочный файл соп/і§.Н должен быть определен корректно. Для 
процессора Репіішп он может выглядеть примерно так: 

#сІеЕіпе СРЕІ РЕШШ 
#сІеЕіпе ШКОШЕТН 32 

Чтобы откомпилировать операционную систему для процессора ШігаЗРАКС, 
нужно использовать другой файл соп/і§.к, содержащий правильные значения для 
процессора іЛігаЗРАКС, возможно, что-то вроде 

#4еПпе СРІ) 1ЛТКА5РАКС 
#4еГіпе иОКОДЕЕІЗТИ 64 

Некоторые читатели могут удивиться, почему переменные СРІІ и Ѵ/ОКИ_ 
ЬЕЫСТН управляются различными макросами. В определении константы Ке§Ыег 
можно сделать ветвление программы, устанавливая ее значение в зависимости от 
значения константы СРІІ, то есть устанавливая значение константы Ке§Ыег рав¬ 
ной 32 бит для процессора Репіішп и 64 бит для процессора ШігаЗРАКС. Однако 
эта идея не слишком удачна. Что произойдет, если позднее мы соберемся перено¬ 
сить систему на 64-разрядный процессор Іпіеі Иапіит? Для этого нам пришлось 
бы добавить третий условный оператор в листинг 12.3, б для процессора Иапіит. 
При том, как это было сделано, нужно только добавить строку 

#с!еЕіпе ИОИууЕМСТН 64 

в файл соп/щ.Н для процессора Ііапіит. 

Этот пример иллюстрирует обсуждавшийся ранее принцип ортогональности. 
Участки системы, зависящие от типа центрального процессора, должны компили¬ 
роваться с использованием условной компиляции, в зависимости от значения кон¬ 
станты СРІІ, а для участков системы, зависимых от размера слова, должен исполь- 
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зоваться макрос \ѴОКБ_ЬЕЫСТН. Те же соображения справедливы и для многих 
других параметров. 

Косвенность 

Иногда говорят, что нет такой проблемы в кибернетике, которую нельзя решить 
на другом уровне косвенности. Хотя это определенное преувеличение, во фразе 
имеется и доля истины. Рассмотрим несколько примеров. В системах на осно¬ 
ве процессора РепСішп при нажатии клавиши аппаратура формирует прерывание 
и помещает в регистр устройства не символ А5СІІ, а скан-код клавиши. Более того, 
когда позднее клавиша отпускается, генерируется второе прерывание, также с но¬ 
мером клавиши. Такая косвенность предоставляет операционной системе возмож¬ 
ность использовать номер клавиши в качестве индекса в таблице, чтобы получить 
по его значению символ А5СІІ. Этот способ облегчает обработку разных клавиа¬ 
тур, существующих в различных странах. Наличие информации как о нажатии, так 
и об отпускании клавиш позволяет использовать любую клавишу в качестве ре¬ 
гистра, так как операционной системе известно, в котором порядке нажимались 
и отпускались клавиши. 

Косвенность также используется при выводе данных. Программы могут выво¬ 
дить на экран символы А5СП, но эти символы могут интерпретироваться как ин¬ 
дексы в таблице, содержащей текущий отображаемый шрифт. Элемент таблицы 
содержит растровое изображение символа. Такая форма косвенности позволяет 
отделить символы от шрифта. 

Еще одним примером косвенности служит использование старших номеров 
устройств в ІШІХ. В ядре содержатся две таблицы, одна для блочных устройств 
и одна для символьных, индексированные старшим номером устройства. Когда 
процесс открывает специальный файл, например /<Іеѵ/Ы0, система извлекает из 
і-узла информацию о типе устройства (блочное или символьное), а также старший 
и младший номера устройств и, используя их в качестве индексов, находит в табли¬ 
це драйверов соответствующий драйвер. Такой вид косвенности облегчает ре¬ 
конфигурацию системы, так как программы имеют дело с символьными именами 
устройств, а не с фактическими именами драйверов. 

Еще один пример косвенности встречается в системах передачи сообщений, 
указывающих в качестве адресата не процесс, а почтовый ящик. Таким образом 
достигается существенная гибкость (например, секретарша может принимать по¬ 
чту своего шефа). 

В определенном смысле использование макросов, как, например, 

#сІеГіпе РК0С_ТАВІ_Е_5І2Е 256 

также представляет собой одну из форм косвенности, так как программист может 
написать программу, не зная фактической величины таблицы. Считается хоро¬ 
шей практикой давать символьные имена всем константам (иногда кроме -1, 0 и 1) 
и помещать их в заголовки с соответствующими комментариями. 

Повторное использование 

Часто возникает возможность использовать повторно ту же самую программу 
в несколько отличном контексте. Это позволяет уменьшить размер двоичных 
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файлов, а кроме того означает, что такую программу потребуется отлаживать все¬ 
го один раз. Например, предположим, что для учета свободных блоков на диске 
используются битовые массивы. Дисковыми блоками можно управлять при по¬ 
мощи процедур аііос и /гее. 

Как минимум эти процедуры должны работать с любым диском. Но мы можем 
пойти дальше в этих рассуждениях. Те же самые процедуры могут применяться 
для управления блоками памяти, блоками кэша файловой системы и і-узлами. 
В самом деле, они могут использоваться для распределения и освобождения ре¬ 
сурсов, которые могут быть линейно пронумерованы. 

Реентерабельность 

Реентерабельность означает свойство программы, позволяющее одновременно 
выполнять эту программу нескольким процессами. На мультипроцессорах всегда 
имеется опасность, что один из процессоров начнет выполнение процедуры, уже 
выполняющейся другим процессором. В этом случае два (или более) потока на 
различных центральных процессорах будут одновременно выполнять одну и ту же 
программу. Если в этой программе существуют области, для которых такая ситуа¬ 
ция нежелательна, доступ к этим (критическим) областям должен защищаться при 
помощи мьютексов. 

Однако в однопроцессорных системах эта проблема также существует. В част¬ 
ности, большая часть операционных систем работает с разрешенными прерывани¬ 
ями. Если прерывания запрещать, то многие сигналы, подаваемые устройствами 
ввода-вывода, будут потеряны и система станет ненадежной. В то время когда 
операционная система выполняет некоторую процедуру, может произойти преры¬ 
вание, и вполне возможно, что обработчик прерываний также начнет выполнение 
этой же процедуры. Если на момент прерывания структуры данных в прерванной 
процедуре находились в противоречивом состоянии (то есть прерванная процеду¬ 
ра начала изменять эти данные, но не успела закончить), обработчик прерываний 
либо будет работать некорректно, либо не сможет работать вообще. 

Такая ситуация может, например, произойти в том случае, если прерываемой 
процедурой является сам планировщик. Предположим, что некий процесс ис¬ 
пользовал свой квант, и операционная система переместила его в конец очереди. 
Во время работы со списком происходит прерывание, в результате которого дру¬ 
гой процесс переходит в состояние готовности и запускает планировщик. Если 
в этот момент очередь будет находиться в противоречивом состоянии, операцион¬ 
ная система, скорее всего, не сможет продолжать работу. Поэтому даже в однопро¬ 
цессорной системе лучше всего большую часть системы делать реентерабельной, 
критические структуры данных защищать мьютексами, а прерывания в некоторых 
случаях вообще запрещать. 

Метод грубой силы 

Применение простых решений под названием метода грубой силы с годами приоб¬ 
рело негативный оттенок, однако простота решения часто оказывается преимуще¬ 
ством. В каждой операционной системе есть множество процедур, которые редко 
вызываются или которые оперируют таким небольшим количеством данных, что 
оптимизировать их нет смысла. Например, в системе часто приходится искать какой- 
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либо элемент в таблице или массиве. Метод грубой силы в данном случае заключа¬ 
ется в том, чтобы оставить таблицу в том виде, в каком она есть, никак не упорядо¬ 
чивая элементы, и производить поиск в ней линейно от начала к концу. Если число 
элементов в таблице невелико (например, не более 100), выигрыш от сортировки 
таблицы или применения хэширования будет невелик, но программа станет гораздо 
сложнее и, следовательно, вероятность содержания в ней ошибок резко возрастет. 

Разумеется, для функций, находящихся в критических участках системы, на¬ 
пример в процедуре, занимающейся переключением контекста, следует предпри¬ 
нять все меры для их ускорения, возможно даже писать их (Боже упаси!) на ас¬ 
семблере. Но большая часть системы не находится в критическом участке. Так, ко 
многим системным вызовам редко обращаются. Если системный вызов Іогк вы¬ 
полняется раз в 10 с, а его выполнение занимает 10 мс, тогда, даже если удастся 
невозможное — оптимизация, после которой выполнение системного вызова Іогк 
будет занимать 0 мс, — общий выигрыш составит всего 0,1 %. Если после оптими¬ 
зации код станет больше и будет содержать больше ошибок, то в данном случае 
лучше оптимизацией не заниматься. 

Проверка на ошибки прежде всего 

Многие системные вызовы могут завершиться безуспешно по многим причинам: 
файл, который нужно открыть, может принадлежать кому-либо другому; создание 
процесса может не удаться, так как таблица процессов переполнена; сигнал не мо¬ 
жет быть послан, потому что процесса-получателя не существует. Операционная 
система должна скрупулезно проверить возможность наличия самых разных оши¬ 
бок, прежде чем выполнять системный вызов. 

Для выполнения многих системных вызовов требуется получение ресурсов, 
например элементов таблицы процессов, элементов таблицы і-узлов или дескрип¬ 
торов файлов. Прежде чем захватывать ресурсы, полезно проверить, можно ли 
выполнить этот системный вызов. Это означает, что всю проверку следует помес¬ 
тить в начало процедуры, выполняющей системный вызов. Каждая проверка долж¬ 
на иметь следующий вид: 

ІЕ (еггог_сопсІШоп) ге1игп(ЕКК0К_ССЮЕ); 

Если системному вызову удается пробраться сквозь все тесты, тогда становит¬ 
ся ясно, что он завершится успешно. В этот момент ему можно выделять ресурсы. 

Если проверки будут перемежаться обращением к ресурсам, то при неудачном 
результате очередного теста системному вызову придется возвращать все получен¬ 
ные ресурсы. Если программа написана не совсем корректно и какой-либо ресурс 
не будет возвращен, операционная система сразу не зависнет. Например, один из 
элементов таблицы процессов может оказаться навечно (до перезагрузки) недо¬ 
ступным. Однако со временем эта ситуация может повториться несколько раз, при 
этом количество недоступных ресурсов будет накапливаться. Наконец, большая 
часть элементов таблицы процессов может стать недоступной, что приведет к за¬ 
висанию системы, причем исправление этой ошибки, скорее всего, окажется край¬ 
не сложным, так как воспроизвести эту ситуацию будет непросто. 

Многие системы страдают подобными «заболеваниями» в форме утечки памя¬ 
ти. Довольно часто программы обращаются к процедуре таііос , чтобы получить 
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память, но забывают позднее обратиться к функции /гее, чтобы освободить ее. Вся 
память системы постепенно исчезает, пока система не зависает. 

Энглер и его коллеги [109] предложили интересный метод проверки на нали¬ 
чие подобных ошибок во время компиляции. Авторы этой книги выяснили, что 
программистам известно множество условий, за соблюдением которых им прихо¬ 
дится следить при написании программы и которые не проверяются компилято¬ 
ром. Так, например, если вы заблокировали мьютекс, то все пути выполнения этой 
программы, начиная с этого места, должны содержать разблокировку мьютекса и 
не должны содержать повторной блокировки того же мьютекса. Авторы книги раз¬ 
работали метод, позволяющий программисту поручить компилятору автоматичес¬ 
ки следить за соблюдением подобных правил. Программист также может указать 
в программе, что выделенная процессу память должна быть освобождена незави¬ 
симо от того, по какой ветви будет продолжаться выполнение программы, а также 
поручить компилятору следить за выполнением множества других условий. 


Производительность 

При прочих равных условиях быстрая операционная система лучше медленной. 
Однако быстрая, но ненадежная операционная система хуже надежной, но мед¬ 
ленной. Поскольку сложные оптимизирующие методы часто приводят к появле¬ 
нию в системе новых ошибок, не следует злоупотреблять оптимизацией. И все же 
существуют области, в которых производительность является критичной и оп¬ 
тимизация стоит затрачиваемых усилий. В следующих разделах мы рассмотрим 
несколько общих методов, которые могут применяться для повышения произво¬ 
дительности там, где это нужно. 

Почему операционные системы 
такие медленные? 

Прежде чем перейти к разговору о методах оптимизации, имеет смысл отметить, 
что в медленности работы многих операционных систем в достаточной мере вино¬ 
ваты сами операционные системы. Например, старые операционные системы, такие 
как М5-Б05 и ІЛЧІХ Ѵегзіоп 7, загружались за несколько секунд. Для загрузки 
современных версий системы ІЛЧІХ и системы \Ѵіпс1о\ѵз 2000 требуется несколько 
минут, несмотря на то, что они загружаются на аппаратуре, работающей в 100 раз 
быстрее. Причина состоит в том, что новые системы выполняют гораздо больше 
действий, нужно это или нет. Например, р1и§-апс1-р1ау облегчает установку новых 
аппаратных устройств, но платой за это является то, что при каждой загрузке опе¬ 
рационная система должна исследовать все аппаратное обеспечение, чтобы опре¬ 
делить, не появилось ли что-либо новое. Сканирование шин занимает время. 

Альтернативный (и, по мнению автора, лучший) подход заключается в том, что¬ 
бы совсем выбросить р1и§-апс!-р1ау, а на экране установить значок, помеченный 
«Установка новой аппаратуры». Установив новое аппаратное устройство, пользо- 
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ватель просто щелкает мышью на этом значке, запуская процедуру сканирования 
шин, вместо того чтобы разрешать операционной системе делать это при каждой 
загрузке. Разработчики операционных систем, безусловно, знали о наличии такой 
возможности. Однако они отказались от нее, в основном потому, что считали 
пользователей не достаточно умными, чтобы правильно выполнить требуемые 
действия (правда, высказано это было в более мягких выражениях). Это всего 
лишь один пример, но можно привести и множество других примеров того, как 
желание сделать систему «дружественной по отношению к пользователю» (или 
«защищенной от дурака», в зависимости от вашей точки зрения) значительно сни¬ 
жало производительность системы. 

Вероятно, больше всего могут добиться разработчики систем в деле увеличе¬ 
ния производительности, если существенно повысят избирательность при добав¬ 
лении к системе новых функций. Вопрос, который должен при этом ставиться, не 
«Понравится ли это пользователям?», а «Стоит ли добавление этой функции той 
неизбежной платы, заключающейся в увеличении программы, снижении скорос¬ 
ти, увеличении сложности и снижении надежности?» Следует включать новую 
функцию, только если преимущества со всей очевидностью перевешивают недо¬ 
статки. Некоторые программисты склонны предполагать, что размеры программы 
будут равны 0, а скорость ее работы будет бесконечной. Как показывают экспери¬ 
менты, эта точка зрения является несколько оптимистичной. 

Другой фактор, также играющий роль в данном вопросе, заключается в рыноч¬ 
ной стратегии производителей программного обеспечения. К тому времени, когда 
версия 4 или 5 некоего программного продукта попадает на рынок, все нужные 
новые функции, включенные в эту версию, у потребителей, вероятно, уже будут. 
Чтобы не снижать уровня продаж, многие производители продолжают произво¬ 
дить новые версии с большим количеством функций. Добавление новых функций 
просто ради добавления новых функций может помочь увеличению продаж, но 
редко способствует увеличению производительности. 

Что следует оптимизировать? 

Общее правило гласит, что первая версия системы должна быть как можно проще. 
Оптимизировать следует только те части системы, которые, очевидно, будут пред¬ 
ставлять собой проблему, поэтому их оптимизация является неизбежной. Одним 
из таких примеров является наличие блочного кэша для файловой системы. Как 
только операционная система отлажена до работоспособного состояния, следует 
произвести тщательные измерения, чтобы понять, на что действительно тратится 
время. Опираясь на эти числа, следует заниматься оптимизацией в тех областях, 
в которых это будет наиболее полезно. 

Вот правдивая история о том, как оптимизация принесла больше вреда, чем 
пользы. Один из студентов автора (имени студента мы здесь называть не будем) 
написал программу тк/зц,ля системы МІ1ѴІХ. Эта программа создает пустую фай¬ 
ловую систему на только что отформатированном диске. На оптимизацию этой 
программы студент затратил около 6 месяцев. Когда он попытался запустить эту 
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программу, оказалось, что она не работает, после чего потребовалось еще 6 допол¬ 
нительных месяцев на ее отладку. На жестком диске эту программу, как правило, 
запускают всего лишь один раз, при установке системы. Она также только раз за¬ 
пускается для каждого гибкого диска — после его форматирования. Каждый за¬ 
пуск программы занимает около 2 с. Даже если бы работа неоптимизированной 
версии занимала 1 мин, то затрата такого большого времени на оптимизацию столь 
редко используемой программы являлась бы непроизводительным расходовани¬ 
ем ресурсов. 

Лозунг, применимый к оптимизации производительности, мог бы звучать так: 

Лучшее — враг хорошего. 1 

Под этим мы подразумеваем, что как только удается достичь приемлемого 
уровня производительности, то попытки выжать последние несколько процентов, 
видимо, уже не стоят затрачиваемых усилий и усложнения программы. Если ал¬ 
горитм планирования достаточно хорош и обеспечивает 90-прцентную загрузку 
центрального процессора, возможно, этого достаточно. Разработка значительно 
более сложного алгоритма, на 5 % лучше имеющегося, не всегда представляет со¬ 
бой удачную идею. Аналогично, если частота подкачки страниц достаточно низка, 
то есть подкачка не представляет собой узкое место, то, как правило, нет смысла 
лезть из кожи вон, чтобы добиться оптимальной производительности. Недопу¬ 
щение сбоев в работе системы представляется намного более важной задачей, 
нежели достижение оптимальной производительности, особенно если алгоритм, 
оптимальный при одном уровне загруженности компьютера, может оказаться не¬ 
оптимальным при другом уровне. 

Выбор между оптимизацией по скорости 
и по занимаемой памяти 

При увеличении производительности программы приходится идти на компромисс 
между сокращением времени выполнения программы и увеличением занимаемой 
ею памяти. Программисты часто оказываются перед выбором между медленным, 
но компактным алгоритмом и более быстрым, но занимающим значительно боль¬ 
ше памяти. Занимаясь важной оптимизацией, следует искать алгоритмы, дающие 
увеличение скорости за счет использования большего объема памяти или, наобо¬ 
рот, сберегающие драгоценную память за счет выполнения большего количества 
вычислений. 

Часто может быть полезен метод, заключающийся в замене небольших проце¬ 
дур макросами. Использование макроса устраняет накладные расходы, связанные 
с вызовом процедуры. Выигрыш оказывается особенно существенным, если про¬ 
цедура вызывается многократно в цикле. Например, предположим, что мы исполь¬ 
зуем битовый массив для учета ресурсов и нам часто приходится узнавать, сколь¬ 
ко единиц свободно в некоторой области битового массива. Для этой цели нам 
нужна процедура Ы(_соип(, считающая количество единичных битов в байте. 
Простая процедура показана в листинге 12.4, а. Эта процедура в цикле перебирает 
биты в байте, считая их по одному на каждом цикле. 
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Листинг 12.4. Процедура для подсчета битов в байте (а); макрос для подсчета 
битов (б); макрос для поиска числа битов в таблице (в) 


Ш іпе ВУТЕ_5І2Е 8 
іпі Ьі^соипКіпТ ЬуТе) 

{ 

іпТ і. соиігі = 0: 

Гог (і = 0: і < ВУТЕ_5І2Е: і++) 
іГ ((Ьуіе » і) & 1) соипІ++; 
геТигп(соипТ); 


/* Байт содержит 8 бит */ 

/* Подсчет битов в байте */ 

/* Цикл по битам байта */ 

/* Если бит равен 1. увеличить на единицу сумму */ 
/* Вернуть сумму */ 


а 

/* Макрос для подсчета суммы битов в байте */ 

#беГіпе ЬП_соипІ(Ь) (Ь&1) + {(Ь»1 )&1) + ((Ь»2)&1) + ((Ь»3)Ш + \ 

((Ь»4Ш) + ((Ь»5)&1) + ((Ь»6Ш) + ((Ь»7)&1) 

б 

/* Макрос для поиска числа битов в таблице */ 

сИаг ЬП$[256] = {0. 1. 1, 2. 1. 2. 2. 3. 1. 2, 2. 3. 2. 3. 3. 4. 1, 2. 2. 3. 2. 3. 3. ...}: 
#с!еГіпе ЬіТ_соиіи(Ь) (іпб) М1$[Ь] 

в 


У этой процедуры два источника неэффективности. Во-первых, ей нужно пере¬ 
давать управление, для чего требуется выделение стека, а после работы процедура 
должна вернуть результат и управление. Эти накладные расходы есть у каждого 
вызова процедуры. Во-вторых, процедура содержит цикл, а с циклом всегда связа¬ 
ны определенные накладные расходы. 

Полностью отличный подход заключается в использовании макроса в лис¬ 
тинге 12.4, б. Это выражение вычисляет сумму битов, последовательно сдвигая ар¬ 
гумент и выделяя при помощи маски младший бит. Этот макрос трудно назвать 
произведением искусства, но он встречается в программе всего один раз. Вызов 
этого макроса выглядит идентично вызову процедуры: 

$ип) = ЬіІ_соипШ:аЫе[і]) : 

Таким образом, если не считать несколько беспорядочного определения, мак¬ 
рос выглядит не хуже процедуры, но он является намного более эффективным, так 
как в случае макроса устраняются как накладные расходы процедурного вызова, 
так и накладные расходы цикла. 

Оптимизация данного алгоритма может быть продолжена. Зачем вообще счи¬ 
тать сумму битов? Почему не посмотреть результат в таблице? В конце концов, 
байт может принимать всего 256 значений, а число бит в байте может быть от О 
до 8. Мы можем объявить массив Ыіх из 256 значений, содержащий значения сумм 
битов, инициализируемые во время компиляции программы. При таком методе во 
время работы программы потребуется всего одна команда обращения к массиву 
по индексу. Соответствующий макрос показан в листинге 12.4, в. 

Показанные выше макросы представляют собой понятные примеры выигры¬ 
ша в скорости за счет увеличения размеров программы. Однако мы могли бы пой¬ 
ти в деле оптимизации еще дальше. Если требуется количество битов в 32-разряд- 
ном слове, то с помощью макроса Ыі_соипі нам потребовалось бы для каждого 
слова выполнить четыре обращения к массиву. Если мы увеличим размер табли- 
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цы до 65 536 элементов, мы можем обойтись всего двумя обращениями к таблице 
на слово за счет значительного увеличения таблицы. 

Поиск значений в таблице может использоваться и в других ситуациях. Напри¬ 
мер, в главе 7 мы обсуждали работу алгоритма сжатия^ЕС, в котором применя¬ 
лось довольно сложное дискретное косинусное преобразование. В альтернативном 
методе сжатия СІР для кодирования 24-разрядных пикселов формата ВСВ при¬ 
меняется поиск в таблице. Однако алгоритм СІР работает только с изображения¬ 
ми, содержащими не более 256 цветов. Для каждого сжимаемого изображения фор¬ 
мируется палитра из 256 цветов, хранящихся в формате КСВ. Сжатое изображение 
состоит из 8-разрядных индексов таблицы вместо 24-разрядных значений цвета, 
благодаря чему достигается сжатие в три раза. Эта идея проиллюстрирована для 
фрагмента изображения 4x4 пиксела на рис. 12.3. Несжатое изображение пока¬ 
зано на рис. 12.3, а. Каждый пиксел здесь представляет собой 24-разрядное число, 
в котором каждый из трех байтов содержит интенсивность красного, зеленого 
и синего цвета. Соответствующее этому фрагменту изображение в формате СІР 
показано на рис. 12.3, б. Палитра цветов, показанная на рис. 12.3, в , хранится пря¬ 
мо в файле СІР. В действительности формат СІР несколько сложнее, но основная 
идея заключается в применении таблицы цветов. 
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Рис. 12.3. Фрагмент несжатого изображения с 24 битами на пиксел (а); тот же фрагмент, 
сжатый при помощи алгоритма СІР с 8 битами на пиксел (б); палитра цветов (в) 

Существует другой способ уменьшить размер изображения, служащий иллюс¬ 
трацией еще одного компромисса. Для описания изображений может использо¬ 
ваться язык программирования РозіЗсгірІ. (В действительности для этой цели 
может применяться любой язык, но РозіЗсгірІ предназначен именно для этого.) 
Многие принтеры имеют встроенный интерпретатор языка РозСЗспрС 

Например, если на изображении имеется прямоугольный блок пикселов одно¬ 
го цвета, программа на языке РозіЗсгірІ для этого изображения будет содержать 
команды для помещения прямоугольника в определенное место изображения и 
заполнения его определенным цветом. Для хранения этих команд потребуется все¬ 
го несколько битов. Когда принтер получает изображение, интерпретатор запус¬ 
кает программу и создает изображение. Таким образом, язык РозіЗсгірС позволяет 
добиться сжатия данных за счет большего объема вычислений. Этот подход диа- 
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метрально противоположен рассматривавшемуся выше примеру оптимизации по 
скорости с поиском значения в таблице, но он также очень полезен, когда не хва¬ 
тает памяти или пропускной способности. 

Другие примеры оптимизации включают структуры данных. Двойные связные 
списки занимают больше памяти, чем одинарные связные списки, зато они часто 
предоставляют более быстрый доступ к элементам списка. Хэш-таблицы занима¬ 
ют еще больше памяти, но еще более ускоряют поиск. Короче говоря, при оптими¬ 
зации участка программы следует уделить особое внимание проблеме компромис¬ 
са между занимаемой памятью и скоростью выполнения программы. 

Кэширование 

Хорошо известным методом повышения производительности является кэширова¬ 
ние. Оно может применяться каждый раз, когда с большой вероятностью можно 
предсказать, что много раз потребуется один и тот же результат. Общий метод 
заключается в том, чтобы выполнить всю работу в первый раз, а затем сохранить 
результат в кэше. При последующих попытках в первую очередь будет проверять¬ 
ся кэш. Если результат находится в кэше, то нужно всего лишь достать его оттуда. 
В противном случае необходимо проделать всю работу сначала. 

Мы уже наблюдали использование кэша в файловой системе, где он хранит 
некоторое количество недавно использовавшихся блоков диска, что позволяет из¬ 
бежать обращения к диску при чтении блока. Однако кэширование может также 
применяться и для других целей. Например, обработка путей к файлам отнимает 
удивительно много процессорного времени. Рассмотрим снова пример из систе¬ 
мы ІШІХ, показанный на рис. 6.35. Чтобы найти файл / изг/азі/тЪох , потребуется 
выполнить следующие обращения к диску: 

1. Прочитать і-узел корневого каталога (і-узел 1). 

2. Прочитать корневой каталог (блок 1). 

3. Прочитать і-узел каталога /изг (і-узел 6). 

4. Прочитать каталог /изг (блок 132). 

5. Прочитать і-узел каталога /изг/азі (і-узел 26). 

6. Прочитать каталог /изг/азі (блок 406). 

Чтобы просто определить номер і-узла искомого файла, нужно как минимум 
шесть раз обратиться к диску. Если размер файла меньше размера блока (напри¬ 
мер, 1024 байт), то, чтобы прочитать содержимое файла, нужно восемь обращений 
к диску. 

В некоторых операционных системах обработка путей файлов оптимизирует¬ 
ся при помощи кэширования пар (путь, і-узел). Например, на рис. 6.35 кэш будет 
содержать первые три записи табл. 12.1 после обработки пути /изг/азі/тЪох. По¬ 
следние три записи попадают в таблицу после обработки других путей. 

Когда файловая система должна найти файл по пути, обработчик путей снача¬ 
ла обращается к кэшу и ищет в нем самую длинную подстроку, соответствующую 
обрабатываемому пути. Если обрабатывается путь /изг/азі/§гапіз/зШ, кэш отве¬ 
чает, что номер і-узла каталога /изг/азі равен 26, так что поиск может быть начат 
с этого места и количество обращений к диску может быть уменьшено на четыре. 
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Таблица 12.1. 

Часть кэша і-узлов для рис. 6.35 

Путь 

Номер і-узла 

/изг 

6 

/изг/азі 

26 

/изг/азі/тЬох 

60 

/изг/азІ/Ьоокз 

92 

/изг/ЬаІ 

45 

/изг/ЬаІ/рарегз.рз 85 


Недостаток кэширования путей состоит в том, что соответствие имени файла 
номеру его і-узла не является постоянным. Представьте, что файл /изг/азІ/тЬох 
удаляется и его і-узел используется для другого файла, владельцем которого мо¬ 
жет быть другой пользователь. Затем файл /изг/азІ/тЪох создается снова, но на 
этот раз он получает і-узел с номером 106. Если не предпринять специальных мер, 
запись кэша будет указывать на неверный номер і-узла. Поэтому при удалении 
файла или каталога следует удалять из кэша запись, соответствующую этому фай¬ 
лу, а если удаляется каталог, то следует удалить также все записи для содержав¬ 
шихся в этом каталоге файлов и подкаталогов 1 . 

Кэшироваться могут не только блоки дисков и пути к файлам. Можно кэширо¬ 
вать также і-узлы. Если для обработки прерываний используются временные по¬ 
токи, для каждого из них требуется стек и некоторый дополнительный механизм. 
Эти использовавшиеся ранее потоки также можно кэшировать, так как обновить 
уже использовавшийся поток легче, чем создать новый (применение кэша позво¬ 
ляет избежать необходимости в выделении новому процессу памяти). Кэширова¬ 
ние может применяться почти для всего, что трудновоспроизводимо. 

Подсказки 

Элементы кэша всегда должны быть корректны. Поиск в кэше может завершиться 
неудачей, но если элемент найден, то его корректность гарантируется, поэтому 
найденный элемент может использоваться без дополнительных хлопот. В некото¬ 
рых системах бывает удобным содержать таблицу подсказок. Подсказки представ¬ 
ляют собой предложения решений, но их корректность не гарантируется. Обра¬ 
щающийся к этой таблице процесс должен сам проверять корректность результата. 

Хорошо известным примером подсказок являются указатели ЕШЬ, содержащи¬ 
еся в \ѵеЬ-страницах. Когда пользователь щелкает мышью на ссылке, он не полу¬ 
чает гарантии, что соответствующая \ѵеЬ-страница находится там, куда указывает 
ІШЬ. В самом деле, может оказаться, что требующаяся страница удалена несколь¬ 
ко лет назад. Таким образом, информация, содержащаяся на \ѵеЬ-странице, пред¬ 
ставляет собой всего лишь подсказку. 

Подсказки также используются при работе с удаленными файлами. Информа¬ 
ция, содержащаяся в подсказке, сообщает нечто об удаленном файле, например 
его местонахождение. Однако, возможно, этот файл уже удален или перемещен 
в другое место, поэтому всегда требуется проверка корректности подсказки. 


Во всех файловых системах удаляться могут только пустые каталоги. — Примеч. перво. 
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Использование локальности 

Процессы и программы действуют не случайным образом. Они оказываются в зна¬ 
чительной степени локальными как во времени, так и в пространстве, и эта ин¬ 
формация может быть использована различными способами для улучшения про¬ 
изводительности. Один хорошо известный пример пространственной локальности 
заключается в том факте, что процессы не прыгают произвольным образом в пре¬ 
делах своего адресного пространства. Как правило, за фиксированный интервал 
времени они используют относительно небольшое количество страниц. Страни¬ 
цы, активно используемые процессом, могут рассматриваться как рабочий набор 
процесса. А операционная система может гарантировать, что этот рабочий набор 
находится в памяти, когда процесс получает управление, тем самым снижается 
количество страничных прерываний. 

Принцип локальности также применим для файлов. Когда процесс выбирает 
конкретный рабочий каталог, многие из его последующих файловых обращений, 
скорее всего, будут относиться к файлам, расположенным в этом каталоге. Произ¬ 
водительность можно повысить, если поместить все файлы каталога и их і-узлы 
близко друг к другу на диске. Именно этот принцип лежит в основе файловой 
системы Вегкеіеу Разі Рііе Зузіеш [231]. 

Другой областью, в которой локальность играет важную роль, является плани¬ 
рование потоков в мультипроцессорах. Как было показано в главе 8, один из мето¬ 
дов планирования потоков заключается в том, чтобы попытаться запустить каж¬ 
дый поток на том центральном процессоре, на котором он работал в прошлый раз, 
в надежде, что какие-нибудь из его блоков все еще находятся в кэше. 

Оптимизируйте общий случай 

Часто бывает полезно различать наиболее частый случай и наименее вероятный 
случай и обращаться с ними по-разному. Обычно различные случаи обрабатыва¬ 
ются совершенно различными программами. Важно, чтобы частый случай рабо¬ 
тал быстро. От алгоритма для редко встречающегося случая достаточно добиться 
корректной работы. 

В качестве первого примера рассмотрим вхождение в критическую область. 
В большинстве случаев процессу будет удаваться вход в критическую область, осо¬ 
бенно если внутри этой области процессы не проводят много времени. Операци¬ 
онная система \Ѵіпс1о\ѵ5 2000 использует это преимущество, предоставляя вызов 
\Ѵіп32 АРІ ЕпѣегСгі1іса15ес1іоп, который является атомарной функцией, проверя¬ 
ющей флаг в режиме пользователя (с помощью команды процессора Т51. или ее 
эквивалента). Если тест проходит успешно, процесс просто входит в критическую 
область, для чего не требуется обращения к ядру. Если же результат проверки 
отрицательный, библиотечная процедура выполняет на семафоре операцию сіомп, 
чтобы заблокировать процесс. Таким образом, в нормальном случае обращение 
к ядру не требуется. 

В качестве второго примера рассмотрим установку будильника (использующе¬ 
го сигналы ІЖІХ). Если в текущий момент ни один будильник не заведен, то про- 
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сто создается запись и помещается в очередь таймеров. Однако если будильник 
уже заведен, его следует найти и удалить из очереди таймера. Так как системный 
вызов аіагт не указывает, установлен ли уже будильник, система должна предпо¬ 
лагать худшее, то есть что он уже заведен. Однако в большинстве случаев будиль¬ 
ник не будет заведен, и поскольку удаление существующего будильника представ¬ 
ляет собой дорогое удовольствие, то следует различать эти два случая. 

Один из способов достижения этой цели заключается в том, чтобы хранить бит 
в таблице процессов, указывающий, заведен ли будильник. Если бит сброшен, 
то программа следует по простому пути (просто добавляется новая очередь тай¬ 
мера без какой-либо проверки). Если бит установлен, то очередь таймера требует 
проверки. 

Управление проектом 

Многие программисты являются вечными оптимистами. Они полагают: чтобы 
написать программу, нужно всего лишь поскорее сесть за клавиатуру и начать на¬ 
бивать символы. Вскоре после этого появится полностью законченная отлажен¬ 
ная программа. Очень большие программы таким способом написать невозможно. 
В следующих разделах мы кратко обсудим вопросы управления большими про¬ 
граммными проектами, особенно управления большими системными проектами. 

Мифический человеко-месяц 

В своей классической книге Фред Брукс, один из разработчиков системы 05/360, 
занявшийся впоследствии научной деятельностью, рассматривает вопрос, почему 
так трудно построить большую операционную систему [44, 46]. Когда большин¬ 
ство программистов встречаются с его утверждением, что специалисты, работаю¬ 
щие над большими проектами, могут за год произвести всего лишь 1000 строк 
отлаженного кода, они удивляются, не прилетел ли профессор Брукс из космо¬ 
са, с планеты Баг. В конце концов, большинство из них помнит, как они создава¬ 
ли программу из 1000 строк всего за одну ночь. Как же этот объем исходного 
текста может составлять годовую норму для любого программиста, чей І() превы¬ 
шает 50? 

Брукс отмечает, что большие проекты, в которых задействованы сотни про¬ 
граммистов, принципиально отличаются от небольших проектов и что результаты, 
достигнутые при работе над небольшим проектом, нельзя переносить на большой 
проект. В большом проекте огромное количество времени тратится на планирова¬ 
ние того, как разделить работу на отдельные модули. При этом нужно детально 
расписать работу модулей и интерфейсы к ним, а также попытаться представить 
себе, как эти модули взаимодействуют, причем до того, как начнется само програм¬ 
мирование. Затем модули по отдельности создаются и отлаживаются. Наконец, 
модули собираются вместе и вся система в целом тестируется. Как правило, при 
этом собранная из работающих по отдельности модулей система работать не хочет, 
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и после сборки и запуска немедленно рушится. Брукс оценивает количество работ 
следующим образом: 

1 /3 планирование; 

1 /6 кодирование; 

1/4 тестирование модулей; 

1 /4 тестирование системы. 

Другими словами, собственно написание программы представляет собой самую 
простую часть проекта. Самым сложным оказывается решить, какими должны 
быть модули, а также заставить эти модули корректно общаться друг с другом. 
В небольшой программе, создаваемой одним программистом, планирование состав¬ 
ляет как раз наиболее легкую часть. 

Заголовком книги Брукс обращает внимание читателя на собственное утверж¬ 
дение о том, что люди и время не взаимозаменяемы. Такой единицы, как челове¬ 
ко-месяц, в программировании не существует. Если в проекте участвуют 15 чело¬ 
век, и на всю работу у них уходит 2 года, то отсюда не следует, что 360 человек 
справятся с этой работой за один месяц, и вряд ли 60 человек выполнят эту работу 
за 6 месяцев. 

У этого явления есть три причины. Во-первых, работа не может быть полностью 
разделена. До тех пор пока не будет закончено планирование и не будет определе¬ 
но, какие модули нужны, а также какими будут интерфейсы, никакое программи¬ 
рование не может даже начаться. При двухлетнем проекте одно лишь планирова¬ 
ние может занять 8 месяцев. 

Во-вторых, чтобы полностью использовать большое число программистов, ра¬ 
боту следует разделить на большое количество модулей, чтобы всех обеспечить 
работой. Поскольку потенциально каждый модуль взаимодействует с каждым мо¬ 
дулем, число рассматриваемых пар модуль-модуль растет пропорционально квад¬ 
рату от числа модулей, то есть квадрату числа программистов. Поэтому большие 
проекты с увеличением числа программистов очень быстро выходят из-под конт¬ 
роля. Тщательные измерения 63 программных проектов подтвердили, что зависи¬ 
мость времени выполнения проекта от количества программистов далеко не так 
проста, как можно предположить, исходя из концепции человеко-месяцев [37]. 

В-третьих, процесс отладки в большой степени является последовательным. 
Если усадить за решение проблемы вместо одного отладчика десятерых, это не 
поможет обнаружить ошибку в программе в десять раз быстрее. На самом деле 
десять отладчиков, вероятно, даже будут работать медленнее одного, так как они 
будут тратить очень много времени на разговоры друг с другом. 

Брукс подводит итоги своего опыта знакомства с большими проектами, фор¬ 
мулируя следующий закон (закон Брукса): 

Добавление к программному проекту на поздней стадии дополнительных люд¬ 
ских сил приводит к увеличению сроков выполнения проекта. 

Недостаток введения в проект новых людей состоит в том, что их необходимо 
обучать, модули нужно делить заново, чтобы их число соответствовало числу 
программистов, требуется провести множество собраний, чтобы скоординиро¬ 
вать работу отдельных групп и программистов и т. д. Абдель-Хамид и Мэдник [1] 
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получили экспериментальное подтверждение этого закона. Слегка фривольный 
вариант закона Брукса звучит так: 

Если собратъ девять рожениц в одной комнате, то они не родят через один месяц. 


Структура команды 

Коммерческие операционные системы представляют собой большие программные 
проекты, которые обязательно требуют участия в работе больших команд раз¬ 
работчиков. Уровень программистов имеет чрезвычайно высокое значение. Уже 
десятки лет известно, что сильнейшие программисты в десять раз продуктивнее 
плохих программистов [284]. Неприятность заключается в том, что когда вам 
нужны 200 программистов, сложно найти 200 программистов высочайшей ква¬ 
лификации. Вам придется согласиться на команду, состоящую из программистов 
самого различного уровня. 

Что также важно в крупном проекте, программном или любом другом, — это 
необходимость архитектурного соответствия. Нужно, чтобы один человек контро¬ 
лировал всю конструкцию. В качестве примера Брукс приводит кафедральный 
собор в Реймсе, постройка которого заняла десятки лет, но архитекторы, сменявшие 
друг друга, не поддались искушению внести в проект собственные идеи и сумели 
сохранить изначальный архитектурный план. В результате было получено архи¬ 
тектурное соответствие, которого не удалось достичь в других соборах Европы. 

В 70-е годы Харлан Миллс попытался объединить наблюдения о различиях 
в уровнях квалификации программистов с необходимостью архитектурного соот¬ 
ветствия и ввел понятие команды главного программиста [17]. Его идея заключа¬ 
лась в том, чтобы организовать программистов в нечто подобное хирургической 
группы, в противоположность бригаде забойщиков свиней. В отличие от послед¬ 
ней команды, в которой у каждого работника по ножу и каждый рубит им направо 
и налево как сумасшедший, в хирургической группе только один хирург держит 
в руке скальпель. Все остальные члены группы лишь ассистируют ему. Предло¬ 
женная Миллсом структура команды из 10 разработчиков показана в табл. 12.2. 


Таблица 12.2. Предложенная Миллсом структура команды из 10 разработчиков 


Должность Обязанности 


Главный программист 
Второй пилот 
Администратор 

Редактор 

Секретари 

Архивариус 

Инструментальщик 

Тестер 

Эксперт по языкам 


Занимается архитектурным дизайном и пишет программу 
Помогает главному программисту и служит резонатором 

Управляет людьми, бюджетом, пространством, оборудованием, 
отчетами и т. д. 

Редактирует документацию, которую должен писать главный 
программист 

Администратору и редактору нужны секретари 

Следит за состоянием архивов программ и документации 

Снабжает главного программиста необходимыми инструментами 

Тестирует программы главного программиста 

(Работает неполный рабочий день). Может дать совет главному 

программисту по языкам программирования 
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Такая структура команды была предложена тридцать лет назад. С тех пор кое- 
что изменилось (так, например, исчезла надобность в консультанте по языкам — 
язык С проще, чем РБ/1). Но необходимость в централизованном управлении ос¬ 
талась. По-прежнему управлять всей схемой должен всего один человек. Хотя ис¬ 
пользование компьютеров позволяет уменьшить штат помощников, но сама идея 
все еще остается в силе. 

Любой большой проект должен быть организован иерархически. На нижнем 
уровне располагается множество маленьких групп, каждую из которых возглав¬ 
ляет главный программист. На следующем уровне группы команд должны коор¬ 
динироваться менеджером. Как показывает опыт, каждый управляемый менедже¬ 
ром человек обходится ему в 10 % рабочего времени, поэтому для каждой группы 
из 10 команд требуется отдельный менеджер. Этими менеджерами также нужно 
управлять и т. д., до вершины дерева. 

Брукс отмечает, что плохие новости плохо распространяются вверх по дереву. 
Джерри Зальтцер из Массачусетсского технологического института назвал этот 
эффект диодом плохих новостей. Ни один программист или менеджер не хочет 
сообщать своему боссу, что проект на 4 месяца отстает от графика и не имеет шан¬ 
сов быть выполненным в срок из-за тысячелетней традиции отрубания головы 
посланнику, принесшему дурную новость. В результате старший менеджер, как 
правило, не имеет никакого представления о состоянии проекта. Когда становит¬ 
ся очевидно, что в срок проект выполнен быть не может, старший менеджер нани¬ 
мает дополнительных людей, после чего в действие вступает закон Брукса. 

На практике большие компании, у которых накоплен значительный опыт в об¬ 
ласти производства программного обеспечения и которые знают, что произойдет, 
если оно создается бессистемно, по крайней мере пытаются действовать правильно. 
Небольшие, новые компании, изо всех сил спешащие прорваться на рынок, напро¬ 
тив, не всегда заботятся о том, чтобы аккуратно производить свое программное 
обеспечение. Эта спешка часто приводит к далеко не оптимальным результатам. 

Ни Брукс, ни Миллс не смогли предвидеть роста производства открытых про¬ 
граммных средств. Хотя в этой области имеется ряд успехов, открытые программ¬ 
ные средства до сих пор рассматриваются, как если бы это была жизнеспособная 
модель производства большого количества качественного программного обеспече¬ 
ния, стоит только пройти эффекту новизны. Вспомните, что в первые годы после 
изобретения радио в эфире доминировали радиолюбители, вскоре им пришлось 
уступить коммерческому радио, а затем коммерческому телевидению. Следует за¬ 
метить, что наиболее удачные проекты открытых программных средств, несомнен¬ 
но, использовали модель главного программиста, то есть всем проектом управлял 
один человек (например, Линус Торвальдс, руководивший разработкой ядра опе¬ 
рационной системы Біпих, и Ричард Столман, направлявший процесс создания 
компилятора СЫИ С). 


Роль опыта 

Наличие опытных разработчиков является критичным при проектировании опе¬ 
рационной системы. Брукс указывает, что большинство ошибок допускается ни 
при программировании, а на стадии проекта. Программисты правильно делают то, 
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что им велят делать. Но если то, что им велели, было неверно, то никакое тестовое 
программное обеспечение не сможет поймать ошибку неверно составленной спе¬ 
цификации. 

Решение, предложенное Бруксом, заключается в отказе от классической моде¬ 
ли разработки (рис. 12.4, а) и в использовании модели, показанной на рис. 12.4, 6. 
Принцип состоит в том, чтобы сначала написать главный модуль программы, ко¬ 
торый просто вызывает процедуры верхнего уровня. Вначале эти процедуры пред¬ 
ставляют собой заглушки. Начиная уже с первого дня система будет транслиро¬ 
ваться и запускаться, хотя делать она ничего не будет. Постепенно в систему будут 
устанавливаться модули. Результат применения такого метода заключается в том, 
что сборка системы проверяется постоянно, поэтому ошибки в проекте обнаружи¬ 
ваются значительно раньше. Таким образом, процесс обучения на собственных 
ошибках также начинается значительно раньше. 



а б 

Рис. 12.4. Традиционное поэтапное проектирование программного обеспечения (а); 
альтернативный метод создания работающей уже с первого дня системы (б) 

Неполные знания представляют собой опасную вещь. В своей книге Брукс опи¬ 
сывает явление, названное им эффектом второй системы. Часто первый продукт, 
созданный группой разработчиков, является минимальным, так как они опасают¬ 
ся, что он не будет работать вообще. Поэтому они опасаются помещать в первый 
выпуск программного обеспечения много функций. Если проект оказывается удач¬ 
ным, они создают следующую версию программного обеспечения. Воодушевлен¬ 
ные собственным успехом, во второй раз разработчики включают в систему все 
погремушки и побрякушки, намеренно не включенные в первый выпуск. В резуль¬ 
тате система раздувается и ее производительность снижается. От этой неудачи 
команда разработчиков трезвеет и при выпуске третьей версии снова соблюдает 
осторожность. 

Это наблюдение отчетливо видно на примере пары систем СТ55-МЩ.ТІС5. 
Операционная система СТ55 была первой универсальной системой разделения 
времени и ее успех был огромен, несмотря на минимальную функциональность 
системы. Создатели операционной системы МІЛ.ТІС8, преемницы СТ58, были 
слишком амбициозны, за что и поплатились. Сами идеи были неплохи, но новых 
функций добавилось слишком много, что сказалось на низкой производительное- 
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ти системы, страдавшей этим недугом в течение долгих лет и так и не получившей 
коммерческого успеха. Третьей в этой линейке была операционная система ІЖІХ, 
разработчики которой проявили значительно большую осторожность и в резуль¬ 
тате добились существенно больших успехов. 

Панацеи нет 

Помимо книги «Мифический человеко-месяц», Брукс написал также статью «N 0 
Зііѵег ВиІІеС» (Панацеи нет), получившую широкий резонанс [45]. В ней он дока¬ 
зывал, что в ближайшие десять лет ни одно средство, поисками которого в те вре¬ 
мена занималось множество людей, не приведет к существенному (на порядок) 
увеличению производительности в создании программного обеспечения. Как пока¬ 
зывает опыт последних лет, он был прав. 

Среди предлагаемых в то время чудодейственных средств были улучшенные 
языки высокого уровня, объектно-ориентированное программирование, искусст¬ 
венный интеллект, экспертные системы, автоматическое программирование, гра¬ 
фическое программирование, верификация программ и программное окружение. 
Возможно, в следующие десять лет мы увидим нечто радикальное, но не исключе¬ 
но, что нам придется довольствоваться постепенными последовательными улуч¬ 
шениями. 


Тенденции в проектировании 
операционных систем 

Предсказывать всегда трудно, особенно будущее. Например, в 1899 году Чарльз 
Дьюэл, возглавлявший тогда Бюро патентов США, предложил тогдашнему пре¬ 
зиденту США Мак-Кинли ликвидировать патентное бюро (а также и рабочее мес¬ 
то Чарльза Дьюэла!), поскольку, как он писал, «все, что можно было изобрести, 
уже изобретено» [58]. Тем не менее прошло всего несколько лет, и на пороге па¬ 
тентного бюро показался Томас Эдисон с заявками на электрические лампы, фо¬ 
нограф и кинопроектор. Сменим батарейки в нашем кристальном шаре и попыта¬ 
емся угадать, что станет с операционными системами в ближайшем будущем. 

Операционные системы с большим 
адресным пространством 

По мере того как на смену 32-разрядным машинам приходят 64-разрядные, стано¬ 
вится возможным главное изменение в строении операционных систем. 32-разряд- 
ное адресное пространство на самом деле не так уж велико. Если попытаться разде¬ 
лить 2 32 байт на всех жителей Земли, то каждому достанется менее одного байта. В то 
же время 2 64 примерно равно 2х10 19 . При этом каждому жителю планеты в 64-раз- 
рядном адресном пространстве можно выделить фрагмент размером в 3 Гбайт. 

Что можно сделать с адресным пространством в 2x10 19 байт? Для начала мы 
можем отказаться от концепции файловой системы. Вместо этого все файлы можно 
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постоянно хранить в памяти (виртуальной). В конце концов, в ней достаточно ме¬ 
ста для более чем миллиарда полнометражных фильмов, сжатых до 4 Гбайт. 

Другая возможность заключается в использовании перманентных объектов. 
Объекты могут создаваться в адресном пространстве и храниться в нем до тех пор, 
пока не будут удалены все ссылки на объект, после чего сам объект автоматически 
удаляется. Такие объекты будут сохраняться в адресном пространстве даже после 
выключения и перезагрузки компьютера. Чтобы заполнить все 64-разрядное ад¬ 
ресное пространство, нужно создавать объекты со скоростью 100 Мбайт/с в тече¬ 
ние 5000 лет. Разумеется, для хранения такого количества данных потребуется 
очень много дисков, но впервые в истории ограничивающим фактором стали фи¬ 
зические возможности дисков, а не адресное пространство. 

При большом количестве объектов в адресном пространстве становится инте¬ 
ресным позволить нескольким процессам работать одновременно в одном адрес¬ 
ном пространстве, чтобы упростить совместное использование объектов. Приме¬ 
нение такой схемы, разумеется, приведет к появлению операционных систем, 
сильно отличающихся от существующих в настоящий момент. Некоторые сооб¬ 
ражения об этой концепции содержатся в [60]. 

Еще один системный аспект, который придется пересмотреть при введении 
64-разрядных адресов, это виртуальная память. При 2 64 байт виртуального адрес¬ 
ного пространства и 8-килобайтных страницах у нас будет 2 31 страниц. Работать 
с обычными таблицами страниц такого размера будет непросто, поэтому потребует¬ 
ся другое решение. Возможно использование инвертированных таблиц страниц, од¬ 
нако также предлагались и другие идеи [321]. В любом случае появление 64-раз¬ 
рядных операционных систем создает новую большую область исследований. 

Сеть 

Современные операционные системы разрабатывались для автономных компью¬ 
теров. Сети были разработаны позднее, и доступ к ним главным образом предо¬ 
ставляется при помощи специальных программ и протоколов, таких как \ѵеЬ-бра- 
узеры, РТР или Іеіпеі. В будущем, возможно, сети будут составлять основу всех 
операционных систем. Автономный компьютер, не подключенный к сети, будет 
столь же редким явлением, как и телефон, не подключенный к линии. И, скорее 
всего, соединения с пропускной способностью в десятки и сотни мегабит в секун¬ 
ду станут нормой. 

Чтобы приспособиться к этому сдвигу парадигм, операционным системам при¬ 
дется измениться. Различие между локальными данными и удаленными данными 
может размыться, так как практически никого не будет беспокоить, где фактичес¬ 
ки хранятся данные. С любыми данными компьютер сможет работать, как с ло¬ 
кальными. В системе МР5 это уже в определенном смысле так, но, похоже, эта тен¬ 
денция будет продолжена и расширена, и в этой области будет достигнута более 
высокая степень интеграции. 

Доступ к Всемирной паутине, для которого в настоящий момент требуются 
специальные программы (браузеры), также может стать полностью интегриро¬ 
ванным в операционную систему. \ѴсЬ-страницы, возможно, станут стандартным 
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способом хранения информации, а эти страницы могут содержать очень широкий 
спектр данных нетекстового формата, включая аудио, видео, программы и т. д., 
и всеми этими данными операционная система будет управлять, как своими ос¬ 
новными данными. 

Параллельные и распределенные системы 

Другой новой областью являются параллельные и распределенные системы. Совре¬ 
менные операционные системы для мультипроцессоров и многокомпьютерных 
систем представляют собой просто стандартные однопроцессорные операционные 
системы с небольшими изменениями в устройстве планировщика, обеспечиваю¬ 
щими несколько лучшую поддержку параллелизма. В будущем, возможно, у нас 
будут операционные системы, в которых параллелизму будет предоставлено цен¬ 
тральное место. Серьезным дополнительным стимулом к этому станет возможное 
использование мультипроцессорных схем для настольных компьютеров. В резуль¬ 
тате может появиться множество прикладных программ, специально разработан¬ 
ных для работы на мультипроцессорах, а также необходимость в лучшей поддерж¬ 
ке этой работы со стороны операционной системы. 

Многокомпьютерные системы, скорее всего, в ближайшие годы будут домини¬ 
ровать среди научных и инженерных суперкомпьютеров, но операционные систе¬ 
мы для них все еще остаются крайне примитивными. Для помещения процессов, 
балансировки загрузки и обмена информацией требуется много работы. 

Современные распределенные системы часто строятся как промежуточное про¬ 
граммное обеспечение, так как существующие операционные системы не предо¬ 
ставляют распределенным приложениям всех необходимых функций. Возможно, 
при проектировании будущих операционных систем будут учитываться рас¬ 
пределенные системы, поэтому все необходимые функции будут присутствовать 
в операционной системе с самого начала. 

Мультимедиа 

Мультимедийные системы стали восходящей звездой в компьютерном мире. 
Никого не удивит, если компьютеры, стереоустановки, телевизоры и телефоны 
будут объединены в одно устройство, обеспечивающее воспроизведение высоко¬ 
качественного звука и видеоизображения, а также подключенного к высокоскоро¬ 
стной сети, что обеспечит быструю загрузку требуемых файлов. Операционные 
системы для этих устройств или даже для автономных аудио- и видеоустройств 
должны существенно отличаться от современных операционных систем. В част¬ 
ности, потребуются гарантии реального времени, и они составят основу устрой¬ 
ства системы. Кроме того, пользователи окажутся очень недовольными, если опе¬ 
рационную систему их телевизоров придется перезагружать через каждый час, 
поэтому к программному обеспечению будут предъявляться более высокие требо¬ 
вания по качеству и устойчивости к сбоям. К тому же размер мультимедийных 
файлов, как правило, очень велик, поэтому от файловой системы требуется спо¬ 
собность эффективной работы с ними. 
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Компьютеры на батарейках 

Без всякого сомнения, мощные настольные персональные компьютеры, вероятно, 
с 64-разрядным адресным пространством, с соединением с высокоскоростной се¬ 
тью, несколькими процессорами и высококачественными изображением и звуком, 
станут нормальным явлением. Их операционные системы должны существенно 
отличаться от современных систем, чтобы обеспечить поддержку всех этих требова¬ 
ний. Однако еще более быстрый сегмент рынка составляют компьютеры, питающи¬ 
еся от батарей, к которым относятся лэптопы, палмтопы, ѵѵеЬ-пады и различные 
телефонные гибриды. Некоторые из них поддерживают беспроводное соединение 
с внешним миром. Другие работают в автономном режиме, а к сети могут подклю¬ 
чаться стационарно. Для них нужны операционные системы, отличающиеся от 
современных меньшими размерами, большей гибкостью и большей надежностью. 
Основу этих систем могут составить различные виды микроядерных и расширяе¬ 
мых систем. 

Эти системы должны будут лучше современных систем поддерживать работу 
с полным соединением (то есть с использованием проводов), со слабым соединени¬ 
ем (с использованием беспроводной связи) и автономную работу, включая накоп¬ 
ление данных перед отключением от сети и проверку непротиворечивости данных 
перед тем, как снова подключиться к сети. Они также должны лучше справляться 
с проблемами мобильности (например, находить лазерный принтер, регистри¬ 
роваться на нем и посылать ему файл по радио). Особое значение для этих сис¬ 
тем имеет управление энергопотреблением, включая продолжительные диалоги 
между операционной системой и приложениями о том, сколько осталось энергии 
в батареях и как ее лучше всего использовать. Также может стать важной дина¬ 
мическая адаптация приложений к крошечным экранам. Наконец, для новых 
режимов ввода и вывода, включая ввод рукописного текста и речевой ввод, в опе¬ 
рационной системе могут потребоваться новые методы, позволяющие повысить 
качество. Маловероятно, что операционная система для питаемого батареями, пор¬ 
тативного беспроводного, управляемого голосом компьютера будет иметь много 
общего с системой, работающей на 64-разрядном мультипроцессоре с четырьмя 
центральными процессорами, с гигабитным оптоволоконным сетевым соединени¬ 
ем. И, разумеется, будет бесчисленное множество гибридных машин, со своими 
собственными требованиями. 

Встроенные системы 

Последняя область, в которой будут плодиться и размножаться новые операцион¬ 
ные системы, — это встроенные системы. Операционные системы в стиральных 
машинах, микроволновых печах, куклах, транзисторных (Интернет?) приемниках, 
МРЗ-проигрывателях, видеокамерах, лифтах и кардиостимуляторах будут отли¬ 
чаться ото всех перечисленных выше и, скорее всего, друг от друга. Каждая из них 
должна быть тщательно скроена под ее конкретное приложение, так как малове¬ 
роятно, что кому-либо придет в голову засунуть карту РСІ в кардиостимулятор, 
чтобы превратить его в контроллер лифта. Поскольку во всех встроенных систе¬ 
мах работает только ограниченный набор программ, известных заранее, можно за¬ 
претить оптимизацию в универсальных системах. 
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Расширяемые операционные системы (например, Рагатесіит н Ехокегпеі) 
оказываются многообещающей идеей для встроенных систем. Их можно сделать 
легковесными или тяжеловесными, в зависимости от потребностей конкретного 
приложения, при этом, правда, следует добиваться непротиворечивости между 
приложениями. Поскольку встроенные системы будут производиться сотнями 
миллионов, это станет главным рынком для операционных систем. 

Резюме 

Проектирование операционных систем начинается с определения их задач. Интер¬ 
фейс должен быть простым, полным и эффективным. Он должен обладать ясной 
парадигмой пользовательского интерфейса, парадигмой исполнения и парадигмой 
данных. 

Система должна быть хорошо структурированной, для чего может быть исполь¬ 
зована одна из нескольких известных технологий, таких как многоуровневые систе¬ 
мы или архитектуры клиент-сервер. Внутренние компоненты должны быть ортого¬ 
нальными друг к другу. Кроме того, следует четко отделить политику от механизма. 
Следует также уделить существенное внимание таким вопросам, как выбор меж¬ 
ду статическими или динамическими структурами данных, именование, время свя¬ 
зывания, а также порядок реализации модулей. 

Производительность является важным вопросом, но следует тщательно выби¬ 
рать способ оптимизации, чтобы не нарушить структуру операционной системы. 
Часто имеет смысл заниматься оптимизацией по скорости или по занимаемой па¬ 
мяти, кэшированием, подсказками, использовать локальность, а также оптимизи¬ 
ровать общий случай. 

Создание системы группой из двух-трех человек отличается от разработки 
большой системы командой из 300 сотрудников. В последнем случае в успехе или 
неуспехе проекта главную роль играют такие вопросы, как структура команды 
и управление проектом. 

Наконец, в ближайшие годы операционные системы должны будут изменить¬ 
ся, чтобы соответствовать новым тенденциям и новым требованиям. К ним могут 
относиться 64-разрядное адресное пространство, высокоскоростное сетевое со¬ 
единение, настольные мультипроцессоры, мультимедиа, переносные компьютеры 
с беспроводной связью, а также огромное количество встроенных систем. Ближай¬ 
шие годы будут весьма интересными для проектировщиков операционных систем. 


Вопросы 

1. Закон Мура описывает явление экспоненциального роста, сходного с рос¬ 
том популяций видов животных, помещенных в новую среду с изобилием 
пищи и отсутствием естественных врагов. В природе кривая экспоненциаль¬ 
ного роста в конце концов становится сигмоидальной, асимптотически стре¬ 
мящейся к некоему пределу, когда обнаруживается ограниченность запасов 
пищи или хищники приспосабливаются к новой добыче. Обсудите факторы, 
способные ограничить рост производительности компьютерной аппаратуры. 
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2. В листинге 12.1 показаны две парадигмы, алгоритмическая и движимая со¬ 
бытиями. Какую парадигму проще всего применить для каждой из следую¬ 
щих типов программ: 

а) компилятор; 

б) программа редактирования фотографий; 

в) программа составления платежной ведомости. 

3. На некоторых ранних моделях компьютера Арріе МасіпіозЬ программа гра¬ 
фического интерфейса пользователя располагалась в ПЗУ. Почему? 

4. Иерархические имена файлов всегда начинаются с вершины дерева. Например, 
имя файла записывается как / шг/а5і/Ъоок$/то52/скар - 12, а не скар- 12/то$2/ 
Ъоокз/азі/изг. Имена БАЗ, напротив, начинаются на дне дерева и двигаются 
вверх. Есть ли какая-либо фундаментальная причина для этого отличия? 

5. Правило Корбато утверждает, что система должна предоставлять минималь¬ 
ный механизм. Ниже приводится список вызовов стандарта Р05ІХ, также 
присутствовавших в системе ІЖІХ Ѵегзіоп 7. Какие из них являются избы¬ 
точными, то есть могут быть удалены без потери функциональности, так как 
та же работа может быть выполнена при помощи простой комбинации ос¬ 
тальных вызовов примерно с той же производительностью? Ассезз, аіагт, 
сіісііг, сіітосі, сіюип, сМгооЕ, сіозе, сгеаі:, <1ир, ехес, ехіЕ, ГсігЫ, Гогк, ^зѣаі, іосЫ, 
кі 11,1 і пк, 1 зеек, тксіі г, шкпоф ореп, раизе, рі ре, геаф зіаѣ, ѣі те, ѣітез, итазк, ипі і пк, 
и'Ьіше, маі'Ь, и мгіЕе. 

6. Предположим, что уровни 3 и 4 на рис. 12.1 переставлены местами. Какие 
последствия окажет это на конструкцию системы? 

7. В системе клиент-сервер, основанной на микроядре, микроядро занимается 
только передачей сообщений. Могут ли процессы пользователя, несмотря 
на это, создавать и использовать семафоры? Если да, то как? Если нет, поче¬ 
му нет? 

8. Аккуратная оптимизация может повысить производительность системных 
вызовов. Рассмотрим случай, в котором каждые 10 мс выполняется один 
системный вызов. Среднее время вызова составляет 2 мс. Насколько уско¬ 
рится процесс, занимавший 10 с, если ускорить выполнение системных вы¬ 
зовов в два раза? 

9. Обсудите тему политики и механизма в контексте розничной торговли. 

10. Операционные системы часто поддерживают два уровня именования: внеш¬ 
нее и внутреннее. В чем различие этих имен в плане 

а) длины; 

б) уникальности; 

в) иерархии. 

11. Один из способов работы с таблицами, размер которых не известен заранее, 
заключается в том, чтобы сделать эти таблицы фиксированными, но когда 
одна таблица заполняется, заменять ее таблицей большего размера, копиро¬ 
вать старые записи в новую таблицу, после чего память, занимаемая старой 
таблицей, освобождается. В чем преимущества и недостатки удвоения раз¬ 
меров таблицы по сравнению с увеличением размеров всего в 1,5 раза? 
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12. В листинге 12.2 флаг / оипсі используется для определения, был ли найден 
РШ. Можно ли не сохранять флаг / оипсі в цикле, а просто проверять значе¬ 
ние переменной р в конце цикла, чтобы определить, был ли найден процесс 
с данным идентификатором? 

13. В листинге 12,3 различия между процессорами Репііиш и ІЛігаЗРАКС скры¬ 
ты при помощи условной компиляции. Может ли использоваться тот же ме¬ 
тод для того, чтобы скрыть различия между компьютером с процессором 
Репііиш и жестким диском с интерфейсом ГОЕ и компьютером с процессором 
Репііиш и жестким диском с интерфейсом 5С5І? Будет ли это удачной идеей? 

14. Косвенность представляет собой метод увеличения гибкости алгоритма. 
Есть ли у этого метода недостатки, и если да, то какие? 

15. Могут ли у реентерабельных процедур быть статические глобальные пере¬ 
менные? Аргументируйте свой ответ. 

16. Макрос в листинге 12.4, б, очевидно, является более эффективным, чем про¬ 
цедура в листинге 12.4, а. Однако этот макрос труден для восприятия. Есть 
ли у него другие недостатки? Если да, то какие? 

17. Допустим, нам нужен способ определить, является ли количество битов 
в 32-разрядном слове четным или нечетным. Разработайте алгоритм, позво¬ 
ляющий определять это как можно быстрее. При необходимости вы можете 
использовать для таблиц до 256 Кбайт ОЗУ. Напишите макрос, выполняю¬ 
щий данный алгоритм. Дополнительное задание : напишите процедуру, вы¬ 
числяющую то же значение, перебирая 32 бит в цикле. Измерьте, во сколь¬ 
ко раз макрос быстрее процедуры. 

18. На рис. 12.3 показано, как файлы формата СІЕ используют 8-разрядные зна¬ 
чения индексов в палитре цветов. Ту же идею можно использовать с 16-раз- 
рядной палитрой цветов. При каких обстоятельствах, если таковые вообще 
существуют, использование 24-разрядной палитры цветов может быть удач¬ 
ной идеей? 

19. Один из недостатков формата СІР состоит в том, что изображение должно 
содержать палитру цветов, увеличивающую размер файла. При каком ми¬ 
нимальном размере файла использование 8-разрядной палитры цветов не 
увеличит размеры файла? А для 16-разрядной палитры цветов? 

20. В тексте было показано, как кэширование путей к файлам может существен¬ 
но ускорить поиск файлов по имени. Другой иногда применяемый метод 
заключается в использовании демона, открывающего все файлы корневого 
каталога и постоянно хранящего их в открытом состоянии, чтобы их і-узлы 
постоянно присутствовали в памяти. Ускоряет ли данный метод поиск фай¬ 
лов по имени? 

21. Даже если удаленный файл не был удален с того момента, когда была запи¬ 
сана подсказка, он мог быть изменен с момента последнего доступа к нему. 
Какую еще информацию было бы полезно записывать? 

22. Рассмотрим систему, накапливающую ссылки к удаленным файлам в виде 
подсказок, например, в формате (имя, удаленный хост, удаленное имя). 
Может случиться так, что удаленный файл будет удален, а затем заменен 
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другим файлом. При этом подсказка может указывать на неверный файл. 
Как можно снизить вероятность появления этой проблемы? 

23. В тексте указывалось, что локальность часто можно использовать для уве¬ 
личения производительности. Но рассмотрим случай, в котором программа 
читает входные данные из одного источника и постоянно выводит данные 
в один или несколько файлов. Может ли попытка использования локально¬ 
сти в файловой системе привести в данном случае к снижению производи¬ 
тельности? Есть ли способ борьбы с этим? 

24. Фред Брукс заявляет, что программист может написать за год всего 1000 строк 
отлаженного кода, однако первая версия системы МШІХ (13 000 строк кода) 
была создана одним человеком менее чем за три года. Как вы объясните это 
несоответствие? 

25. Основываясь на формуле Брукса о 1000 строк кода на программиста в год, 
оцените количество денежных средств, потраченных на создание операци¬ 
онной системы \Ѵіпйо\ѵз 2000. Предположим, что программист обходится 
компании в 100 000 долларов в год (включая такие накладные расходы, как 
компьютеры, офисное пространство, секретарская поддержка и руководство). 
Правдоподобный ли получился ответ? Если нет, то какое из предположе¬ 
ний могло быть неверно? 

26. Память компьютеров становится все дешевле и дешевле, и уже можно 
представить себе компьютер с большой памятью, питающейся от батарей, 
вместо жесткого диска. При текущих ценах сколько может стоить такой пер¬ 
сональный компьютер? Предположим, что для самой дешевой машины до¬ 
статочно гигабайтного КАМ-диска. Будет ли такая машина конкурентоспо¬ 
собной на рынке? 

27. Назовите несколько особенностей обычной операционной системы, которые 
не нужны во встроенной системе, используемой внутри прибора. 

28. Напишите на языке С процедуру, складывающую два заданных параметра с 
двойной точностью. Напишите процедуру, используя условную компиля¬ 
цию, таким образом, чтобы эта процедура работала как на 16-разрядных, так 
и на 32-разрядных компьютерах. 

29. Напишите программу, помещающую случайно сформированные короткие 
строки в массив, а затем находящую заданную строку в массиве при помо¬ 
щи (а) простого линейного поиска (метод грубой силы) и (б) более сложно¬ 
го метода по вашему выбору. Перекомпилируйте ваши программы для раз¬ 
меров массивов, варьирующихся от небольших до настолько больших, какие 
сможет поддержать ваша система. Оцените производительность обоих ме¬ 
тодов. При каком размере массивов производительность обоих методов бу¬ 
дет одинаковой? 

30. Напишите программу, моделирующую находящуюся в памяти файловую 
систему. 
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В предыдущих 12 главах был рассмотрен широкий спектр вопросов. Цель этой гла¬ 
вы заключается в том, чтобы помочь заинтересованным читателям продолжить 
изучение операционных систем. Первый раздел представляет собой список книг, 
рекомендованных для дальнейшего чтения. Второй раздел является алфавитным 
списком всех книг, на которые есть ссылки в данной книге. 

Помимо этих списков литературы, в поисках новых статей по вопросам опера¬ 
ционных систем стоит заглянуть в материалы очередного симпозиума Ассоциации 
по вычислительной технике (АСМ — Аззосіаііоп Іог Сотриііп§ МасЫпегу) по воп¬ 
росам принципов операционных систем, проводимого ежегодно, а также в отчеты 
ежегодной международной конференции по распределенным вычислительным 
системам (ІЕЕЕ). Представляют интерес и материалы симпозиума по проекти¬ 
рованию и реализации операционных систем Ц5ЕЫІХ. Кроме того, интересные 
статьи об операционных системах печатаются в журналах АСМ Тгапзасііопз оп 
Сотриіег Зузіетз и Орегайщ Зузіетз Кеѵіеѵв. 

Литература, рекомендуемая 
для дальнейшего чтения 

В следующих разделах будут даны некоторые рекомендации для дальнейшего 
чтения. В отличие от статей, упомянутых в разделах, озаглавленных «Исследо¬ 
вания в области...» в тексте книги и посвященных текущим исследованиям, эти 
ссылки, по большей мере, представляют собой вступительные или учебные изда¬ 
ния. Они могут использоваться для освещения материала, представленного в дан¬ 
ной книге, с иной стороны. 

Введение и общие труды 

1. Каѵі еі аі., «Сотриіег Зузіетз КезеагсЬ: ТЬе Ргеззиге із Оп». 

В каком направлении продвигаются исследования систем? Что является важ¬ 
ным в настоящий момент? Как обстоит дело с разработкой прочных, предсказуе¬ 
мых систем? А с микросхемами, состоящими из миллиарда транзисторов, и со все¬ 
мирными системами с миллиардом пользователей? В этой статье можно найти эти 
и другие вопросы, а также ответы на них. 
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2. Мііофсіс, «Орегаііп^ Зузіетз: >Іо\ѵ апсі іп іЬе Риіиге». 

Представьте, что вы можете задать шести ведущим мировым экспертам серии 
вопросов по теме операционных систем и путям их развития. Получите ли вы оди¬ 
наковые ответы? Подсказка: нет. В книге вы можете познакомиться с их мнениями. 

3. ЗіІЬегксЬасх с с аі., Аррііесі Орегашщ Зу&іет Сопсеріз. 

Общее руководство по операционным системам. В нем обсуждаются процес¬ 
сы, управление хранением данных, распределенные системы и защита. Рассмат¬ 
риваются три конкретных примера: ІЖІХ, Ілпих и \Уіпсіо\Ѵ5 Ш\ Обложка цели¬ 
ком покрыта динозаврами. Какое отношение имеют они к операционным системам 
2000-го года, неясно. 

4. Зсаіііпцк, ОрегаІіп§ Зузіетз, 4ск Ед. 

Еще один учебник по операционным системам. В нем описываются все тради¬ 
ционные темы, а также включено небольшое количество материала по распреде¬ 
ленным системам. 

5. Зсеѵепк, Асіѵапсед Рго§гаттіп§ іп IНе ІІШХ Епѵігоптепі. 

Эта книга сообщает, как написать программы на языке С, использующие ин¬ 
терфейс системных вызовов ІЖІХ и стандартную библиотеку С. Примеры осно¬ 
ваны на версиях системы ІЖІХ Зузіет V Кеіеазе 4 и 4.4В5Э. Подробно описано 
отношение этих реализаций к стандарту РОЗІХ. 

Процессы и потоки 

1. Апбгешз апсі ЗсЬпеісіег, «Сопсеріх апсі Моіаііопх Гог Сопсиггеп! Ргоцгаішпіпц». 

Учебный и обзорный материал по процессам и межпроцессному взаимодей¬ 
ствию, в котором, среди прочего, описывается активное ожидание, семафоры, мо¬ 
ниторы, передача сообщений и другие технологии. В этой статье также показыва¬ 
ется, как эти понятия встроены в различные языки программирования. 

2. Веп-Агі, Ргіпсіріез о/ Сопсиггепі Рго§гаттіп§. 

Эта небольшая книга полностью посвящена проблемам межпроцессного взаи¬ 
модействия. Среди прочих тем в отдельных главах обсуждаются взаимные исклю¬ 
чения, семафоры, мониторы и задача обедающих философов. 

3. ЗіІЬегзсЬаІг еі аі., Аррііесі Орегаііщ Зу&іетп Сопсеріз. 

Главы с 4 по 6 посвящены теме межпроцессного взаимодействия, включая пла¬ 
нирование, критические области, семафоры, мониторы и классические проблемы 
межпроцессного взаимодействия. 

Взаимоблокировка 

1. СоИтап еі аі., «Зузіет Эеасііоскз». 

Эта книга представляет собой краткое введение во взаимоблокировки. В ней 
рассказывается о причинах их возникновения и способах их предотвращения или 
обнаружения. 
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2. Нок, «Боше Оеасііоск РгорегГіез оі Сотриіег Бузіешз». 

Обсуждение взаимоблокировок. Холт вводит модель направленных графов, 
которую можно использовать для анализа некоторых тупиковых ситуаций. 

3. Ыоог апб Магзіапф «ТЬе ОеасИоск РгоЫеш: Ап Оѵегѵіе\ѵ». 

Учебное пособие по взаимоблокировкам, в котором особое внимание уделяет¬ 
ся системам баз данных. Описывается множество моделей и алгоритмов. 


Управление памятью 

1. Оеппіп§, «Ѵігіиаі Мешогу». 

Классическая статья по многим вопросам виртуальной памяти. Деннинг был од¬ 
ним из пионеров в этой области. Он же является автором концепции рабочего набора. 

2. Оеппіп§, «\Уогкіп§ Беіз Разі апб Ргезепі». 

Хороший обзор многочисленных алгоритмов управления памятью и странич¬ 
ной подкачкой. Включена всеобъемлющая библиография. 

3. КпиіЬ, Тке Ап о/ Сотриіег Рго§гаттіп§. Ѵоі. 1. 

В этой книге обсуждаются и сравниваются различные алгоритмы управления 
памятью, такие как «первый подходящий», «лучший подходящий» и т. д. 

4. БіІЬегзсЬаІг еі аі, Аррііесі Орегаііп§ Зузіет Сопсеріз. 

Главы 9 и 10 посвящены управлению памятью, включая свопинг, страничную 
подкачку и сегментацию. Упоминаются различные алгоритмы замещения страниц. 


Ввод-вывод 

1. СЬеп еі аі., «КАШ: Ні§Ь Ретіогшапсе КеІіаЫе Бесопбагу 5іога§е». 

Параллельное использование нескольких жестких дисков для ускорения вво¬ 
да-вывода является современной тенденцией в профессиональных системах. Ав¬ 
торы обсуждают эту идею и изучают различные способы организации, сравнивая 
производительность, стоимость и надежность. 

2. Сотриіег , МагсЬ 1994. 

Этот выпуск журнала Сотриіег содержит восемь статей по передовым техно¬ 
логиям ввода-вывода, в которых обсуждаются такие темы, как моделирование, 
накопители с высокой производительностью, кэширование, ввод-вывод для парал¬ 
лельных компьютеров и мультимедиа. 

3. Сеізі апб Батек «А Сопііпииш оі Бізк 5сЬеби1іп§ А1§огкЬшз». 

В данной книге обсуждается обобщенный алгоритм планирования переме¬ 
щений блока головок диска. Приводятся результаты всесторонних экспериментов 
и моделирования. 

4. СіЬзоп апсі Ѵап Меіег, «ИеІ\ѵогк АііасЬсб 5іога§е». 

С появлением Интернета возросли потребности в больших накопителях для 
\ѵеЬ-страниц, баз данных и других серверов. В результате было разработано множе¬ 
ство схем присоединения к сети автономных запоминающих устройств. В данной 
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статье обсуждается несколько архитектурных решений, предназначенных для дос¬ 
тижения этой цели. 

5. РІ§, «Асіѵапсез іп Бізк ТесЬпо1о§у: Регіопнапсе Іззиез». 
Производительность системы может зависеть от различных факторов, таких 

как линейная плотность записи, скорость вращения диска, количество головок и 
количество секторов на дорожке. Эти вопросы, а также их влияние на производи¬ 
тельность обсуждаются в этой легкой для чтения статье по технологии дисков. 

6. Киешшіег апб \Ѵі1кез, «Ап Іпігобисііоп Іо Эізк Вгіѵе Мобе1іп§». 

Первая часть этой статьи посвящена современным дисковым накопителям и их 
внутренней работе, включая такие вопросы, как перемещение головок, зониро¬ 
вание, перекос дорожек, резервирование, кэширование, опережающее чтение и 
многое другое. Во второй части статьи описывается моделирование дисковых 
накопителей. 

7. \Уа1кег апб Сга§оп, «ІпіеггирГ Ргосеззіпё іп СопсиггепГ Ргосеззогз». 
Реализация точных прерываний на суперскалярных компьютерах представляет 

собой чрезвычайно перспективную область исследований. Хитрость заключается в 
том, чтобы преобразовать состояние процессора в последовательную форму и сде¬ 
лать это быстро. В данной статье обсуждаются различные вопросы устройства компь¬ 
ютеров и возможные компромиссные решения. 

Файловые системы 

1. НагЬгоп, Я/е ЕузСетз. 

Книга по устройству файловых систем, приложениям и производительности. 
Описываются как структура, так и алгоритмы. 

2. МсКизіск еі аі., «А Разі Рііе Зузіеш іог ІШІХ». 

Файловая система для ІШІХ была полностью переделана для версии 4.2 В5Э. 
В этой статье описывается устройство новой файловой системы с особым акцен¬ 
том на ее производительности. 

3. ЗіІЬегзсЬаІг еі аі., Аррііесі Орегайщ Зузіет СопсерСз. 

Глава 11 посвящена теме файловых систем. Среди прочих тем в ней описыва¬ 
ются операции с файлами, методы доступа, каталоги и вопросы реализации. 

4. Зіа11іп§5, Орегайщ Зузіетз, 2пй Ей. 

В главе 14 содержится существенное количество материала о безопасном окру¬ 
жении, а также о хакерах, вирусах и других угрозах. 

Мультимедийные операционные системы 

1. АСМСотрийщ Зигѵеуз, Вес. 1995. 

Этот выпуск АСМ Сотрийщ Зигѵеуз содержит 21 краткую статью по различ¬ 
ным аспектам мультимедиа, варьирующихся от низкоуровневых технических во¬ 
просов до вопросов прикладного уровня. 
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2. Сотриіег , Мау 1995. 

Темой этого выпуска журнала Сотриіег является мультимедиа. Этой теме жур¬ 
нал уделил целых шесть статей. После краткого вступления статьи рассказывают 
об интерактивном телевидении, мультимедийных серверах, об управлении иссле¬ 
дованиями и о приложениях в медицине и обучении. 

3. Ьее, «Рагаііеі Ѵібео Зегѵегз: А Тиіогіаі». 

Многие организации хотят предоставлять видео по заказу, в результате чего 
возникает потребность в масштабируемых, отказоустойчивых параллельных 
видеосерверах. Здесь обсуждаются главные вопросы, касающиеся их создания 
и включающие архитектуру серверов, чередующиеся наборы, политику размеще¬ 
ния, балансировку нагрузки, избыточность, протоколы и синхронизацию. 

4. Ьезііе еі аі., «ТЬе Эезі§п аші Ішріешепіаііоп оі ап ОрегаІіп§ Зузіет Іо Зиррогі 
ЭізігіЬиіесІ Миііітесііа Арріісаііопз». 

Многие попытки реализации мультимедиа основывались на добавлении новых 
функций к существующей операционной системе. Альтернативный подход, опи¬ 
санный в данной статье, заключается в том, чтобы начать все сначала и создать с 
нуля новую операционную систему для мультимедиа, без необходимости в обрат¬ 
ной совместимости с чем бы то ни было. В результате получается операционная 
система, принципиально отличная по своему устройству от существующих. 

5. КесЫу, «І/О Іззиез іп а Миііітесііа Зузіет». 

Когда говорят о производительности компьютера, как правило, имеют в виду 
производительность центрального процессора. Однако для мультимедиа про¬ 
изводительность ввода-вывода по меньшей мере так же важна. Именно этой теме 
и посвящена данная статья. Среди прочих вопросов в ней обсуждаются плани¬ 
рование дисков, вопрос зависимости производительности системы от количества 
оперативной памяти, а также управление доступом. 

6. Зііагаш апб Иап, «Миііітесііа Зегѵегз». 

У мультимедийных серверов есть множество отличий от обычных файловых 
серверов. Авторы подробно обсуждают эти различия, особенно в области плани¬ 
рования, запоминающей подсистемы и кэширования. 

Многопроцессорные системы 

1. АЬшасІ, «Сі§ап1іс Сіизіегз: \УЪеге Аге ТЬеу апсі \УЪаІ Аге ТЬеу Эоіп§?». 

Чтобы понять идею, лежащую в основе современных больших многокомпью¬ 
терных систем, стоит прочитать эту статью. В ней описывается сама идея, а также 
рассматриваются некоторые наиболее крупные из работающих сегодня систем. 
Учитывая действие закона Мура, можно смело предполагать, что упоминаемые 
в этой статье размеры будут удваиваться примерно каждые 2 года. 

2. ВЬоефап§ еі аі., «Іізег-Ьеѵеі Кеіхѵогк Іпіегіасе Ргоіосоіз». 

Все увеличивающееся количество многомашинных систем для повышения 
производительности работают с сетевой интерфейсной картой в пространстве 
пользователя. В результате подобного подхода появляется множество вопросов 
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проектирования, одиннадцать из которых обсуждаются в данной статье. Также 
сравниваются несколько существующих систем. 

3. Сотриіег, Бес 1996. 

В этом выпуске журнала Сотриіег содержится восемь статей о мультипроцес¬ 
сорах. Одна из них является учебной по вопросу семантики совместно используе¬ 
мой памяти, но остальные восемь посвящены мультипроцессорным приложени¬ 
ям и производительности. 

4. ЭиЪоіз еі аі., «ЗупсЬгопігаІіоп, СоЬегепсе, апб Еѵепі: Огбегіп§ іп МиШрго- 
Се550Г5>>. 

Учебная статья по вопросам синхронизации в мультипроцессорных системах 
с общей памятью. Однако некоторые идеи в равной мере применимы также к од¬ 
нопроцессорным системам и системам с распределенной памятью. 

5. К\ѵок апб АЬтаф «Зіаііс ЗсЬеби1іп§ АІ^огііЬтз Іог АІ1осаІіп§ Эігесіесі Тазк 
СгарЬз Іо Миіііргосеззогз». 

Оптимальное планирование заданий на многомашинной системе или мульти¬ 
процессоре возможно, когда характеристики всех заданий известны заранее. Про¬ 
блема заключается в том, что расчет оптимального планирования занимает слиш¬ 
ком много времени. В данной статье авторы обсуждают и сравнивают 27 известных 
алгоритмов для различных способов решения этой проблемы. 

6. Ьап§епс1оеп еі аі., «МобеЬ Іог АзупсЬгопош Мезза^е Напс11іп§». 

Производительность многомашинных систем в значительной степени зави¬ 
сит от производительности системы передачи сообщений, особенно от того, как 
обрабатываются поступающие сообщения. Основными вариантами являются 
активные сообщения, функции обратного вызова и временные потоки. В данной 
статье авторы описывают все три способа обработки сообщений, а также срав¬ 
нивают результаты экспериментов, произведенных на одной и той же аппаратной 
платформе. 

7. Р го сіе еС аі., ОіхігіЬиіесІ Зкагесі Метогу: Сопсеріз апсі Зузіетз. 

Это собрание из 28 опубликованных ранее статей представляет собой хорошее 
начало для знакомства с распределенной памятью совместного доступа. Здесь 
собрано множество классических статей по моделям, алгоритмам и вопросам реа¬ 
лизации. 

8. ЗСепзСгот еі аі., «Тгепбз іп ЗЬагесІ Метогу Миіііргосезыщ*». 

В каком направлении развиваются мультипроцессоры? Авторы полагают, что 
будущее скорее за небольшими мультипроцессорами, чем за большими. Они также 
обсуждают модели, архитектуру и параллельное программное обеспечение. 

9. \Уа1с1о, «Аііѵе апсі \Уе11: ^пі ТесЬпо1о§у Тобау». 

Эта статья представляет собой хорошую отправную точку для знакомства с сис¬ 
темой ^пі, ее компонентами и их интерфейсами. Возможно, иллюстрируя способ 
распространения информации в будущем, автор, вместо обычной библиографии, 
снабдил свою статью ІЖЬ-ссылками на \ѵеЬ-страницы. 
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Безопасность 

1. Сотриіег, РеЬ 2000. 

Темой этого выпуска журнала Сотриіег является биометрика, которой посвя¬ 
щены шесть журнальных статей. Они варьируются от введения в предмет до раз¬ 
личных специфических технологий, вопросов конфиденциальности и юридичес¬ 
ких аспектов. 

2. Оеппіп§, «ТЬе ЫшТесІ Зіаіез ѵз. Сгаі§ ЫеісІогЬ-. 

Когда юный хакер обнаружил и опубликовал информацию о том, как работает 
телефонная система, ему было предъявлено обвинение в компьютерном мошенни¬ 
честве. В статье описывается это судебное дело, затронувшее многие фундаменталь¬ 
ные понятия, как, например, свобода слова. Следом за статьей несколько человек 
высказывают свои особые мнения, а Деннинг предоставляет контраргументы. 

3. Веппігщ, Іп/оппаііоп \Ѵаг/аге апсіЗесипіу. 

Информация стала оружием, применяемым как в настоящей войне, так и в борь¬ 
бе корпораций. Участники информационной войны не только стараются атаковать 
информационные системы противника, но также защитить собственные системы. 
В этой замечательной книге автор описывает каждый мыслимый аспект, относя¬ 
щийся к стратегии защиты и нападения, от фальсификации данных и до сетевого 
анализатора пакетов. Обязательное чтение для всех, кто серьезно интересуется 
вопросом компьютерной безопасности. 

4. НаЬіег апсі МагкоД, СуЪегрипк. 

Три захватывающие истории о молодых хакерах, вламывающихся в компьюте¬ 
ры по всему миру, рассказанные компьютерным обозревателем Ыеи> Уогк Тітез 
(МагкоВ). Сотриіег , РеЬ 2000. 

5. іоЬпзоп апсі ^обіа, «Ехр1огіп§ Зіе§апо§гарЬу: $ееіп§ іЬе Ыпзееп». 

У стеганографии долгая история, начинающаяся в те дни, когда тайное посла¬ 
ние писалось на выбритой голове посланника, после чего приходилось ждать, пока 
у посланника отрастут волосы. Сегодня применяются цифровые технологии, хотя 
зачастую они оказываются не менее сложными. Эта статья представляет собой 
хорошо написанное введение в данный предмет. 

6. ЬисІ\ѵі§, Тке Сіапі Віаск Воок о/ Сотриіег Ѵігизез, 2п<1 есі. 

Если вы хотите написать антивирусное программное обеспечение и вам необ¬ 
ходимо понять, как работают вирусы, вплоть до самого нижнего уровня, эта книга 
для вас. В ней подробно обсуждается каждая разновидность вирусов, а для боль¬ 
шинства из них также предоставляется фактический код на гибком диске. Однако 
для понимания книги обязательно требуется умение программировать на ассемб¬ 
лере Репііиш. 

7. Мііорсіс, «ЗесигіГу апсі Ргіѵасу». 

Проблема безопасности имеет много граней, включающих операционные сис¬ 
темы, сети, конфиденциальность и т. д. ( В данной статье публикуются интервью, 
взятые у шести экспертов в области безопасности. 
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8. №сЬепЬег§, «Сотриіег Ѵігиз-Апііѵігиз Соеѵоіиііоп». 

Как только разработчики антивирусного программного обеспечения находят 
способ обнаружения и нейтрализации некоторых классов компьютерных вирусов, 
создатели вирусов делают очередной шаг вперед, совершенствуют свои «произве¬ 
дения» и снова оказываются на шаг впереди. В данной статье обсуждаются раз¬ 
личные аспекты этой игры в кошки-мышки. Автор не страдает чрезмерным опти¬ 
мизмом и считает, что разработчики антивирусного программного обеспечения не 
могут выиграть эту войну, так что пользователей компьютеров утешить нечем. 

9. РЯее§ет, Зесигііу іп Сотриііп§, 2псІ е<1. 

Хотя по вопросу компьютерной безопасности написано много книг, в боль¬ 
шинстве из них затрагивается только вопрос сетевой безопасности. В этой книге 
также обсуждается эта тема, но помимо этого три главы посвящены вопросу без¬ 
опасности операционных систем. Таким образом, эта книга представляет собой 
хороший дополнительный источник информации но этой теме. 


ІЖІХ и Ыпих 

1. Воѵеіапсі Сезаіі, ІІп(ІетіапгІіп§гке Ыпих Кетеі. 

Эта книга, вероятно, является самым лучшим изданием, содержащим всеобъ¬ 
емлющее обсуждение темы ядра операционной системы Ыпих. В ней описывают¬ 
ся процессы, управление памятью, файловые системы, сигналы и многое другое. 

2. ІЕЕЕ, Іп/отгаііоп Тесііпоіору — РогіаЫе Орегаііп§ Зузіет Іпіег/асе (РОЗІХ), 
Рагі 1: Зузіет Арріісаііоп Рго§тт Іпіег/асе (АРІ) [С Ьап§иа§е]. 

Это стандарт. Некоторые разделы вполне удобочитаемы, особенно дополне¬ 
ние В, «Каііопаіе апсі МоІез» (обоснования и примечания), благодаря которому 
часто становится понятно, почему то или иное сделано именно так, а не иначе. 
Одно из преимуществ ссылки на стандарт заключается в том, что в этом докумен¬ 
те по определению нет ошибок. Если какой-либо типографской ошибке в макросе 
удается преодолеть процесс редактирования, то после этого она уже не ошибка, а 
официальный факт. 

3. Ьеѵѵіпе, РОЗІХ Рго&гаттег’в Сиіхіе. 

Эта книга описывает стандарт РОЗІХ более подробно, чем документы стандар¬ 
та, а также включает обсуждения с примерами темы преобразования старых про¬ 
грамм в стандарт РОЗІХ и методы разработки новых программ для среды РОЗІХ. 

4. Махѵѵеіі, Ыпих Соге Кетеі Соттепіагу. 

Первые 400 страниц этой книги содержат подмножество кода ядра операцион¬ 
ной системы Ыпих. Последние 150 страниц представляют собой комментарий к 
коду, что соответствует стилю классической книги Джона Лайонза [211]. Если вы 
хотите понять ядро Ыпих во всех мельчайших деталях, эта книга поможет вам на¬ 
чать это непростое дело. Следует предупредить читателя: чтение 40 000 строк на 
языке С — занятие не для всех. 

5. МсКизіск еі аі., ТНе Ыезщп апсіІтріетепіаііоп о/ іке 4.4 В5В Орегаііп§5узіет. 

Заглавие книги говорит само за себя. Но на самом деле эта книга может также 

рассматриваться как общее руководство по ІЖІХ вообще, так как внутреннее устрой- 
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ство различных версий системы ІЖІХ весьма сходно. Это отличный источник 
информации для всех, кто хочет узнать о внутреннем устройстве системы ІЖІХ. 

ѴѴіпсІоѵѵз 2000 

1. Сизшпапо апсі ЗеІЬу, «Но\ѵ МісгозоД ВиіЫз 5о1(лѵаге». 

Вы никогда не задумывались о том, как вообще кому-то удалось написать про¬ 
грамму, состоящую из 29 миллионов строк (как АУіпсІосѵз 2000), да еще и заста¬ 
вить ее работать? Чтобы понять, как используется цикл создания и тестирования 
программ корпорации Місгозоіі для управления очень большими программными 
проектами, читайте эту статью. 

2. К'огіоп еі аі., Сотріеіе Сиісіе іо Шпсіош 2000 Рго/еззіопаІ. 

Если вы ищете книгу, обсуждающую вопросы настройки и использования АУіп- 
сіо\ѵ5 2000, а также довольно подробно описывающую многие дополнительные 
особенности, такие как реестр, файловые системы РАТ и ШТ5, АсГіѵеХ, ЭСОМ 
и работа в сети, то это правильный выбор. Эта книга занимает свое место между 
массой книг, сообщающих, где и что нажать, чтобы получить тот или иной эффект, 
и книгой Соломона и Руссиновича [309]. 

3. Кесгог апсі Ке\ѵсоіпег, Шп32 Рго§гаттіп§. 

Если вы ищете одну из тех 1500-страничных книг, в которых дается краткое 
изложение того, как писать программы для системы \Ѵіпс1о\ѵя, это не плохой экземп¬ 
ляр. Среди прочих тем, в ней описываются окна, устройства, графический вывод, 
ввод с клавиатуры и мыши, печать, управление памятью, библиотеки и синхрони¬ 
зация. Для чтения книги требуется знание языка программирования С или С++. 

4. Зоіотоп апсі КиззіпоѵісЬ, Ітісіе \ѴіпсІош$ 2000, Зпі есі. 

Если вы хотите научиться работать в АУіпсІосѵз 2000, для этого существуют 
сотни книг. Если же вы хотите узнать, как устроена операционная система АУіп- 
сіо\ѵ5 2000, то эта книга окажется лучшим выбором. В ней описывается, и доволь¬ 
но подробно, множество внутренних алгоритмов и структур данных. Никакая дру¬ 
гая книга не сравнится с этой. 

Принципы проектирования 

1. Вгоокз, «ТЬе МуіЬісаІ Мап МопіЬ: Еззауз оп ЗоЙдѵаге Еп§іпеегіп§». 

Фред Брукс был одним из разработчиков операционной системы 05/360. Он на 
собственном опыте научился отличать то, что работает, от того, что не работает. Со¬ 
веты, содержащиеся в этой остроумной, развлекательной и информативной книге, 
столь же ценны сегодня, “как и четверть века назад, когда эта книга была написана. 

2. Сооке еі аі., «ІЖІХ апсі Веуопсі: Ап ІпІегѵіе\ѵ \ѵіі1і Кеп ТЬошрзоп». 

Разработка операционных систем в значительной мере представляет собой 
искусство, нежели науку. Поэтому хороший способ узнать о предмете — слушать 
экспертов в этой области. Вряд ли можно найти лучшего эксперта, чем Кен Томп¬ 
сон, который был одним из разработчиков систем ІЖІХ, Іпіегпо и Ріап 9. В этом 




998 Библиография 


пространном интервью Томпсон делится своими мыслями по поводу истории 
и перспектив данной области. 

3. СогЬаІо, «Оп ВиіЫіп§ ЗузТетз ТЬаТ \Ѵі11 Раіі». 

В своей лекции по поводу получения премии Тьюринга основатель системы 
разделения времени высказывает примерно те же соображения, что и Брукс в кни¬ 
ге Муікісаі Мап-Мопік. Он приходит к выводу, что все сложные системы в конце 
концов ждет крах и, чтобы иметь хоть какой-то шанс на успех, абсолютно необхо¬ 
димо избегать сложности и придерживаться простоты и элегантности проекта. 

4. Сго\ѵ1еу, Орега(іп§ Зузіетз: А Ѳеящп - Огіепіесі Арргоаск. 

В большинстве книг по операционным системам просто описываются основ¬ 
ные понятия (процессы, виртуальная память и т. д.), а также приводится несколь¬ 
ко примеров, но ничего не говорится о том, как проектировать операционные сис¬ 
темы. Эта книга уникальна тем, что данной теме в ней посвящено четыре главы. 

5. Ьашрзоп, «НіпТз іог Сошриіег ЗузТет Эезі§п». 

Батлер Лэмпсон, один из ведущих разработчиков передовых операционных 
систем в мире, за годы опыта собрал множество подсказок, предложений и руко¬ 
водящих указаний и поместил их в эту увлекательную и информативную статью. 
Как и книга Брукса, эта статья является обязательным чтением для каждого чес¬ 
толюбивого разработчика операционных систем. 

6. \ѴігіЬ, «А Ріеа іог Ьеап 5оіі\ѵаге». 

Никлаус Вирт, знаменитый и опытный разработчик систем, выступает в дан¬ 
ной статье в защиту простого и компактного программного обеспечения, основан¬ 
ного на нескольких простых понятиях, и против той разбухшей мешанины, какой 
является большая часть коммерческого программного обеспечения. Он доказыва¬ 
ет свою точку зрения на примере собственной системы ОЬегоп, представляющей 
собой ориентированную на работу в сети, основанную на графическом интерфей¬ 
се пользователя операционную систему, помещающуюся в 200 Кбайт, включая 
компилятор ОЬегоп и текстовый редактор. 
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аренда, 634 

протокол обнаружения, 634 
служба поиска, 634 
боііеі расширения, 482 
6РЕС, 514 
ЗѴМ, 86, 703 
ЗѴМ-код, 705 

I- 

І_ВА, 339 
ЮТ, 292 
І.Е5, 475 
І_іпба, 630 

пространство кортежей, 630 
шаблон, 631 
І_іпих, 35, 743 

алгоритм планирования, 774 
потоки, 769 

управление памятью, 789 
файловая система, 817 
І-НІІ, 250 


м 

Мазіег Рііе ТаЫе, 914 
МЭ5, 649 

Метогу МападетепШпіІ, 51 

Меззаде-Раззіпд Іпіегіасе, 149 

МРТ, 914 

МІІЧІХ, 35,742 

ММІІ, 51 

МоШ, 38, 399 

МРЕС, 517 

макроблок, 518 
МРІ, 149 

МЗЭОЗ, 37,486,836 

эмуляция в ѴѴІпбоѵѵз 2000, 886 
МІД.ТІС5, 33—35, 287, 736 

N 

ЫС-МиМА, 565 

ЫеѵѵТесІіпоІоду Рііе Зузіет, 910 
ЫРЗ, 819 

архитектура, 819 
протоколы, 820 
реализация, 822 
ЫРІІ, 251 
ЫНІІ, 247 
ЫТРЗ, 910 
ЫиМА, 559, 565 

О 

ОЯВ, 624 
05/360, 31,32 

дефекты системы безопасности, 676 
ОЗР, 742 

Р 

РСІ, 56 
РЭА, 43 
РЭР-11, 35 

Репііит, сегментация, 291 

РЕЕ, 268 

РІС, 894 

РЮ, 73, 757 

ріид апсі ріау, 57 

Розіііоп Іпберепсіепі Собе, 894 

РОЗІХ, 35, 72, 741 

управление потоками, 763 
Р5ѴѴ, 45 

Я 

г-узел, 823 
ПАЮ, 339, 340 
НАМ, 48 

Напбот Ассезз Метогу, 48 
НМ5, 522 
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гооі, 826 
ВРС, 594 
В5А, 648 
гѵѵх-биты, 66 

3 

5АСІ., 928 
зсап-ЕОР, 550 
зсгірі кіббу, 655 
5С5І, 57 
5ЕСАМ, 506 
Зесигііу Юепііііег, 927 
5ЕТІІЮ, 827 
ЗНА, 649 
збеІІ, 60, 66 
ЗЮ, 927 
5І.ЕО, 340 
ЗИМ, 401 
ЗМР, 569 
зіагѵаііоп, 151 
ЗѴЮ, 741 

Зузіет Ассезз Сопігоі Узі, 928 
Зузіет V, 35,741 

Т 

ТСВ, 717 
ТСР, 796 
ТСР/ІР, 740, 744 

ТЕЫЕХ, дефекты системы безопасности, 675 
Іегтсар, 382 
ПВ, 241 
ТОРЗ-20, 430 

ы 

ІІАВТ, 375 
ІЮР, 796 
III, 742 
ІІЮ, 61,825 
ІІМА, 559 
ІІМС5, 737 
ІІМХ, 35, 38, 735, 737 
Вегкеіеу, 740 
РЭР-11, 737 

алгоритм планирования, 771 
безопасность, 825 
ввод-вывод, 793 

дефекты системы безопасности, 674 

загрузка, 776 

задачи, 746 

интерфейсы, 747 

история, 736 

обзор, 746 

оболочка, 749, 760 

переносимая, 738 

потоки, 768 

процессы, 756 


ІІМХ ( продолжение ) 
сеть, 795 
стандартная, 740 
страничная подкачка, 785 
структура ядра, 754 
управление памятью, 779 
утилиты, 752 
файловая система, 802 
Ѵ7, 493 

ІІМХ Іпіегпаііопаі, 742 
ирсаІІ, 121 
ІІРІІ., 616 
115В, 57 

ІІзег Юепіііісаііоп, 61 

V 

ѵ-узел, 823 
ѴАЭ, 896 
ѵепиз, 622 
ѵісе, 622 

ѴІПиаІ Аббгезз Оезсгіріог, 896 
ѴМ/370, 84 

ѵѵ 

ѵгеЬ-браузер, 616 
ѵгеЬ-страница, 616 
«/ібдеі, 399 
ѴѴіп32 АРІ, 79, 846 
ѴѴІпбоѵ/з 2000, 836 
МРТ, 914 

алгоритм замещения страниц, 898 
безопасность, 926 
ввод-вывод, 903 
главная файловая таблица, 914 
драйверы устройств, 907 
загрузка, 888 

исполняющая система, 859 

история, 840 

критическая секция, 878 

межпроцессное взаимодействие, 877 

обработка страничных прерываний, 897 

объект, 863 

планирование, 881 

программирование, 840, 845 

процессы, 873 

реестр, 849 

сокет, 878 

структура системы, 852 
управление памятью, 890 
файловая система, 910 
ядро, 857 

\Л/іпбо\л/Б 95, история, 837 
\Л/іпбо\л/з98, 490 
история, 837 
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ѴѴіпсіоѵѵб Огіѵег МосІеІ, 907 
ѴѴіпсіоѵѵб Ме, 38, 838 
ѴѴіпсіоѵѵб МіІІеппіит ЕсІІІІоп, 838 
ѴѴіпсіоѵѵб N1 38, 839 
ѴѴЗСІоск, 257 

X 

ХѴѴіпсІоѵѵ Зувіет, 38,397 
Х-клиент, 398 
Х-сервер, 398 
Х-терминал, 397 
ХІІЬ, 399 


А 

абсолютное имя пути, 441,804 
абсолютный путь, 804 
автодозвон, 653 
автомонтировка, 820 
агент, 699 
адаптер, 306 
объекта, 625 

адресное пространство, 59 
активация планировщика, 120 
активное 

ожидание, 54,131,322 
сообщение, 594 
алгоритм, 257 
МЭ5, 649 
РБР, 268 
ЫРУ, 251 
Бсап-ЕЭр 550 
ЗЗР, 358 

балансировки нагрузки, 602 
графовый, 603 
инициируемый, 604 
торгов, 605 
банкира, 203 

несколько видов ресурсов, 205 
один вид ресурсов, 203 
быстрый подходящий, 231 
замещения страниц, 245 
РІРО, 248 
Ши, 250 
N141, 251 
ЫНЫ, 247 
РЕЕ, 268 
ЫЫІХ, 786 
ѴѴіпсіоѵѵб 2000, 898 
ѴѴЗСІоск, 257 
вторая попытка, 248 
глобальный, 267 
локальный, 267 
оптимальный, 246 
рабочий набор, 253 


алгоритм ( продолжение) 
резюме, 259 
старение, 252 
часы, 249, 787 

первый подходящий участок, 230 
Петерсона, 132 
планирования, 157 
ЕЭР, 523 
І_іпих, 774 
ЯМЗ, 522 
УЫІХ, 771 
ѴѴіпсіоѵѵб 2000, 881 
гарантированное планирование, 171 
двухуровневый, 578 
задачи, 161 

интерактивные системы, 167 
категории, 161 

кратчайшая задача — первая, 165, 170 
лотерея, 171 

многомашинная система, 601 
мультимедиа, 519 
мультипроцессор, 576 
наименьшее оставшееся время 
выполнения, 165 
несколько очередей, 170 
первым пришел — первым 
обслужен, 164 
планирование потоков, 175 
приоритетное планирование, 168 
реального времени, 173, 520 
родственное, 578 
системы пакетной обработки, 163 
справедливое планирование, 172 
трехуровневое планирование, 165 
циклическое планирование, 167 
распределения процессоров, 602 
самый 

неподходящий участок, 231 
подходящий участок, 230 
следующий подходящий участок, 230 
управления допуском, 507 
часы, 250 

шифрования ВЗА, 648 
алфавитно-цифровой терминал, 373 
аналогово-цифровой преобразователь, 509 
аномалия Билэди, 261 
антивирусная техника, 689 
проверка 

поведения, 694 
целостности, 694 
сканер вирусов, 690 
аппаратная часть 
дисков, 337 
таймеров, 367 

устройств ввода-вывода, таймер, 367 
аппаратно-независимое растровое 
изображение, 396 
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аппаратное обеспечение 
ввода-вывода, 304 
диск, 337 
дисплей, 385 
клавиатура, 374 
мышь, 383 
компьютера, 43 
апплет, 699 
архивация, 462 
архитектура, 24 

архитектурная согласованность, 944 
асимметричная цифровая абонентская 
линия, 503 

асинхронный вызов, 591 
процедуры, 858 
ассоциативная память, 241 
атака 

с помощью переполнения буфера, 671 
системы безопасности, 666, 673 
логическая бомба, 669 
переполнение буфера, 671 
потайная дверь, 670 
троянский конь, 666 
фальшивая программа регистрации, 668 
атрибут файла, 431 
аутентификация, 147 
пользователя, 650 
оклик-отзыв, 659 
с использованием, 651,660,663 

Б 

базовая 

запись, 914 

система ввода-вывода, 219 
базовый 

приоритет, 883 
регистр, 50, 224 
барьер, 149 

безопасное состояние, 202 
безопасность, 66, 642 
Заѵа, 705 
ІІЫІХ, 825 
ѴѴІпсІоѵѵз 2000, 926 
вызовы ѴѴІП32АРІ, 929 
беспроводная связь, 411 
библиотека совместного доступа, 286 
биграмма, 647 
бит 

5ЕТІЛ0, 827 

ожидания активизации, 136 
присутствия/отсутствия, 235 
битовая карта, 228 
битовый массив, 228 
блок управления процессом, 105 
блокировка 

без монополизации, 806 
с монополизацией, 806 
файл, 806 


блокирующая сеть, 564 
блокирующий вызов, 591 
блочное 

кэширование, 545 
устройство, 305, 327 
блочный 
кэш, 471 

специальный файл, 65, 428, 794 
большое адресное пространство, 981 
бригадное планирование, 581 
брокер объектных запросов, 624 
буфер быстрого преобразования адреса, 241 
программное управление, 242 
буферизация, 331 
двойная, 332 
буферный кзш, 471,799 

В 

ввод-вывод, 63, 304 
ЭМА, 311 
ІІЫІХ, 793 
ѴѴІпсІоѵѵз 2000, 903 
отображаемый на память, 307, 308 
программное обеспечение, 319 
программные уровни, 324 
прямой доступ к памяти, 311,323 
управляемый прерываниями, 323 
вектор 

прерываний, 55, 105, 316 
ресурсов, 196 
векторная графика, 385 
венгерская нотация, 391 
взаимное исключение, 128,129 
активное ожидание, 129 
алгоритм Петерсона, 132 
запрещение прерываний, 130 
переменные блокировки, 130 
строгое чередование, 130 
взаимоблокировка, 61, 184 
определение, 188 
условия, 188 
взломщик, 651,652 
видео 

по заказу, 503 
поступательное, 512 
смешанный сигнал, 512 
цифровое, 512 

чересстрочная развертка, 512 
видеоОЗУ, 385 
видеоконтроллер, 385 
видеопамять, 385 
видеосервер, 503 
виртуальная 

машина, 25, 84 
Заѵа, 86, 703 
память, 225, 232 

виртуальное адресное пространство, 233 
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виртуальный адрес, 51,233 
вирус, 678 

атака отказа в обслуживании, 679 
восстановление, 696 
драйвера устройства, 685 
заражающий исходные тексты 
программ, 686 
компаньон, 680 
макрос, 686 
методы борьбы, 689 
паразитический, 682 
перезаписывающий, 680 
пипетка, 679 
полезная нагрузка, 680 
полиморфный, 693 
полостной, 683 

поражающий загрузочный сектор, 684 
предохранение, 695 
резидентный, 683 
сценарии 

нанесения ущерба, 678 
распространения, 687 
вирусный сканер, 690 
вмонтированная файловая система, 77 
внешняя фрагментация, 287 
внутренняя фрагментация, 271 
возможность, 713 
волокно, ѴУІпбоѵге 2000, 875 
волшебный символ, 750 
впускной планировщик, 165 
временный поток, 593 
время 

отклика, 163 
связывания, 959 

всеобщее скоординированное время, 368 

всплывающий поток, 593 

встроенные системы, 984 

вторая попытка, 248 

второстепенное устройство, 331 

выделенное устройство ввода-вывода, 334 

вызов 

ѴѴІп32АРІ 

безопасность, 929 
ввод-вывод, 905 
управление, 876, 895 
файловая система, 912 
удаленной процедуры, 594 
высоконадежная вычислительная база, 717 
выход из тупика, 198 
откат, 199 

принудительная выгрузка ресурса, 199 
уничтожение процессов, 199 

Г 

гарантированное планирование, 171 
гибкая система реального времени, 173 
гиперкуб, 584 


гиперссылка, 616 
главная 

загрузочная запись, 356, 444 
файловая таблица, 914 
главное устройство, 331 
глобальная 
сеть, 609 

таблица дескрипторов, 292 
голодание, 211 
графический 
адаптер, 385 

интерфейс пользователя, 37,383 
программное обеспечение, 388 
гроздь рабочих станций, 582 
группа, 711 

проникновения, 673 
процессов, 758 
цилиндров, 816 
грязный бит, 240 

д 

двоичный 

семафор, 138 

экспоненциальный откат, 610 
двойная буферизация, 332 
двойной 

косвенный блок, 494,815 
тор, 584 

двухуровневое планирование, 578 
двухфазовое блокирование, 210 
дейтаграммная служба, 613 
с подтверждениями, 613 
декодирование, 514 
демон, 100,336,757 
записи 

модифицированных страниц, 901 
отображенных страниц, 901 
менеджер 

балансового множества, 899 
рабочих наборов, 899 
печати, 127 
поток 

обнуления страниц, 902 
свопера, 900 
страничный, 785 
дескриптор, 846 
защиты, 928 
процесса, 103 
файла, 64, 435, 808, 820 
детишки со сценариями, 655 
дефектный 
блок, 464 
сектор, 361 

дефекты системы безопасности, 674 
03/360, 676 
ТЕЫЕХ, 675 
ІІІѴІІХ, 674 
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децибел, 509 
джиттер, 506 
джиффи, 775 
диаметр, сеть, 584 
динамически подсоединяемая 
библиотека, 870 
динамический диск, 904 
диод плохих новостей, 979 
диск, 337 
СЭ-В, 348 
СЭ-РЮМ, 344 
СЭ-РІѴѴ, 351 
ЭѴО, 351 
ЮЕ, 337 

аппаратная часть, 337 
магнитный, 337 
раздел, 356 
форматирование, 353 
чередование секторов, 356 
дисковая 

квота, 460 
ферма, 542 

дисковое планирование, 357 
динамическое, 549 
мультимедиа, 547 
статическое, 547 

дискреционное управление доступом, 720 
диспетчер, 113 
памяти, 51,233 
дисциплина линии связи, 801 
домен защиты, 708 
дорожка, 48 
доступ к файлам, 430 
доступность системы, 643 
дочерний процесс, 60, 757 
драйвер устройства, 53,326 
ѴѴІпбоѵѵБ 2000, 862,907 
единообразный интерфейс, 330 
драйвер-фильтр, 910 
дружественный интерфейс, 37 

Е 

единицы измерения, 92 

Ж 

Желтая книга, 346 
жесткая 

связь, 444 

система реального времени, 173 

3 

завершение процесса, 101 
зависание процесса, 151 
заголовок сектора, 307 
заголовочный файл, 753 


загрузка 
ІІЫІХ, 776 
ѴѴІпбоѵѵБ 2000, 888 
загрузочный 
блок, 444 
сектор, 888 
задание, 28 

ѴѴІпсіоѵѵб 2000, 873 
задатчик последовательности, 628 
закон Ципфа, 540 

замещение страниц по запросу, 253 
запрещение прерываний, 130 
захват цикла, 313 
зашифрованный текст, 646 
защита 

памяти, 224 

паролей в системе ІІЫІХ, 656 
защищенная система, 717 
Зеленая книга, 347 
злоумышленник, 644 
значение, реестр, 849 
зуб вампира, 609 

И 

идеальное тасование, 564 
идентификатор 

безопасности, 927 
группы, 61,825 
пользователя, 61,825 
процесса, 73, 757 

идентификация по длине пальцев, 664 
иерархия 

памяти, 217 
процессов, 102 

избежание взаимоблокировок, 200 
несколько видов ресурсов, 205 
именование, 957 
файлов, 425 
имя пути, 63, 441,804 
абсолютное, 441,804 
относительное, 441,804 
инверсия приоритета, 134,886 
инвертированная таблица страниц, 244 
индекс-узел, 449 
инкрементная 

архивация, 463 
резервная копия, 463 
Интернет, 610 
Интернет-протокол, 614 
Интернет-червь, 697 
интерпретатор команд, 60 
интерпретация, 703 
интерфейс 

ѴѴіп32АРІ, 846 
виртуальной памяти, 275 
графических устройств, 393,861 
драйвер-ядро, 798 
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интерфейс ( продолжение ) 
драйвера, 413 
передачи сообщений, 149 
пользователя, парадигма, 945 
прикладных программ, 79 
системных вызовов, 948 
исполняющая система, ѴѴІпсіоѵѵб 2000, 859 
использование потоков, 111 
истинное время, 369 

К 

кадр, 346, 511 
канал, 65 

канонический режим, 377 
карманный компьютер, 43 
карта 

клавиш, 388 
памяти, 786 

хранящая информацию, 660 
каталог, 63,428, 438 
С Р/М, 484 
ІЗО 9660, 478, 479 
МЗ-ЭОЗ, 486 
ІІМІХѴ7, 493 

ѴѴІпсіоѵѵб 2000, 920 \ 

ѴѴІпсіоѵѵб 98, 490 
двухуровневая система, 439 
иерархическая система, 440 
корневой, 438 

одноуровневая система, 438 
рабочий, 441, 804 
распределенная система, 618 
реализация, 451 
спулера, 127,336 
текущий, 441,804 
каталог 

спулера, 336 
спулинга, 336 

каталоговый мультипроцессор, 565 
качество обслуживания, 506,612 
квант, 167 
квантование, 515 
квота, диск, 460 
кластерный компьютер, 582 
клиентский 
процесс, 87 
суррогат, 594 
ключ 

реестр, 849 
файл, 428 
шифрования, 646 
код исправления ошибок, 307 
кодирование, 514 
звука, 509 
изображения, 511 
кодовая страница, 388 
кодово-импульсная модуляция, 510 
козел отпущения, 690 


кольцо защиты, 296 
команда 
ТРАР, 70 

главного программиста, 978 
защиты, 719 
тигров, 673 
коммутация 
каналов, 585 

пакетов с промежуточным хранением, 584 
компакт-диск, 58, 344 
компьютер 

второе поколение, 28 
первое поколение, 28 
питающийся от батарей, 984 
третье поколение, 30 
четвертое поколение, 36 
конвейер, 45,751 
конечный автомат, 115 
контекст устройства, 393 
контрмеры, 665 
контроллер устройства, 306 
контрольная точка, 199 
конфиденциальность данных, 643 
координатный 

коммутатор, 561 
переключатель, 562 
копирование при записи, 274, 767, 894 
корневая файловая система, 64 
корневой 

каталог, 63 
ключ, реестр, 849 
кортеж, 630 
косвенность, 965 
косвенный блок, 494, 815 
Красная книга, 344 

кратчайшая задача — первая, 165,170 
криптография, 645 
критическая 
область, 128 
секция, 128 
куб, 584 
кэш, 113 

со сквозной записью, 473 
кэш-память, 47 
кэш-строка, 47 
кэширование, 973 
ѴѴІпсіоѵѵб 2000, 931 
мультимедиа, 544 
файл, 471 
файловое, 546 

Л 

линейный адрес, 293 

линия последовательной передачи, 374 

логическая 

адресация блокоа, 339 
архивация, 464 
бомба, 669 
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ложное совместное использование 
памяти, 599 
локальная 
сеть, 609 

таблица дескрипторов, 292 
локальность, 975 
обращений, 253 
лотерейное планирование, 171 

м 

магазинный алгоритм, 262, 264 

магическое число, 429 

макроблок, МРЕС, 518 

маркер доступа, 927 

маршрутизатор, 610 

матрица защиты, 709 

машина с конечным числом состояний, 115 

машинный язык, 23 

международный 

союз телекоммуникаций ІТІІ, 514 
стандарт 13 9660, 348 

межпроцессное взаимодействие, 60, 126, 847 
менеджер 

ріид-апб-ріау, ѴѴІпсіоѵѵб 2000, 860 
балансового множества, 899 
безопасности, ѴѴІпсіоѵѵб 2000, 860 
ввода-вывода, ѴѴІпсіоѵѵб 2000, 859 
вызова локальной процедуры, 

ѴѴІпсіоѵѵб 2000, 861 
конфигурации, ѴѴІпсіоѵѵб 2000, 861 
кэша, ѴѴІпсіоѵѵб 2000, 860 
объектов, ѴѴІпсіоѵѵб 2000, 859 
памяти, 217 

ѴѴІпсіоѵѵб 2000, 860 
процессов, ѴѴІпсіоѵѵб 2000, 860 
рабочих наборов, 899 
энергопотребления, ѴѴІпсіоѵѵб 2000, 861 
метафайл, 394 
метод, 391,624 

грубой силы, 966 
механизм 

защиты, 642, 707 
и политика, 88, 174, 282, 955 
планирования, 174 
микроархитектурный уровень, 22 
микрокомпьютер, 36 
микропрограмма, 23 
микроядро, 87 

Мифический человеко-месяц, 976 
младшее устройство, 78, 794 
многозадачность, 32, 98 
моделирование, 221 
степень, 221 

фиксированные разделы, 219 
многомашинная система, 582 
аппаратное обеспечение, 583 
планирование, 601 


многомашинная система ( продолжение) 
программное обеспечение, 587 
соединительная сеть, 583 
многопоточная программа, 123 
многопоточность, 107 
многопоточный процесс, 107 
многопроцессорная система, 97 
многоступенчатые коммутаторные сети, 563 
многоуровневая 
защита, 720 
система, 83,951 
безопасности, 720 
мобильная программа, 699 
моделирование 

взаимоблокировок, 189 
страничной организации памяти, 261 
модель 

Белла-Ла Падулы, 720 
Биба, 721 
клиент-сервер, 87 
потока, 107 
процессов, 97 
рабочего набора, 254 
модуль управления памятью, 217 
монитор, 141 

виртуальной машины, 84 
обращений, 702,707,718 
моноалфавитная подстановка, 646 
моноалфавитный подстановочный шифр, 646 
монолитная система, 81 
монтирование файловой системы, 77 
мост, 610 

мультикомпьютер, 582 
мультимедиа, 502 
мультимедийная система, 502, 983 
алгоритмы планирования, 519 
дисковое планирование, 547 
кодирование 
звука, 509 
изображения, 511 
парадигмы файловой системы, 526 
размещение файлов, 532 
сервер, 526 
сжатие данных, 513 
файл, 507 

мультипрограммирование, 98 
мультипроцессор, 559 
СС-М11МА, 565 
ЫС-М11МА, 565 
ІЧІІМА, 565 

аппаратное обеспечение, 559 
каталоговый, 565 
координатный коммутатор, 561 
многоступенчатая сеть, 563 
общая шина, 559 
операционная система, 567 
планирование, 576 
с общей памятью, 559 
синхронизация, 571 
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мусорная корзина, 462 

мутационный движущий механизм, 693 

мьютекс, 139,764 

мэйнфрейм, 28 

мягкий таймер, 371 

н 

надежная 

система, 716, 717 
служба, 612 

надежность, файловая система, 461 
надежный алгоритм хэширования ЗНА, 649 
наименьшее оставшееся время 
выполнения, 165 
настройка адресов, 224 
небезопасное состояние, 203 
неблокирующая сеть, 562 
неблокирующий вызов, 591 
недостающий блок диска, 468 
независимость 

от местоположения, 620 
от устройств, 319 
неканонический режим, 377 
необратимая функция, 648 
непериодический процесс, 173 
непосредственный файл, 918 
неприоритетное планирование, 160 
неприятель, 644 
нерезидентный атрибут, 917 
неточное прерывание, 318 

О 

обнаружение взаимоблокировки, 193 
оболочка, 60, 66, 749, 760 
оборотное время, 162 
обработанный символьный поток, 801 
обработка 

ошибок, 361 

страничного прерывания, 277 
ѴѴІпсІоѵѵз 2000, 897 
образ памяти, 59 
обратный вызов, 121 
обслуживаемый процесс, 87 
обслуживающий процесс, 87 
общие права, 715 
объект, 624 
АРС, 858 
РРС, 858 

ѴѴІпсІоѵѵз 2000, 863 
безопасность, 710 
диспетчеризации, 858 
драйвера, 904 
устройства, 909 
оверлей, 232 

одинарный косвенный блок, 494, 815 
однозадачная система, 218 


одноразовый пароль, 658 
ожидание готовности, 54, 322 
ОЗУ, 48 

оклик-отзыв, 659 
окно, 388 

оконные расширения адреса, 895 
оконный менеджер, 399 
онтогенез повторяет филогенез, 39 
оперативная память, 48 
оперативное запоминающее устройство, 48 
операции с каталогами, 442 
операционная система, 22 
МІІЧІХ, 742 
МШТІСЗ, 736 
ІІІЧІСЗ, 737 
ІЖІХ, 735 
встроенная, 43 
история, 27 
менеджер ресурсов, 26 
мультимедийная, 502 
мультипроцессор, 567 
пакетная обработка, 29 
понятия, 59 

производительность, 968 
разработка, 938 
расширенная машина, 24 
реализация, 951 
реального времени, 42 
смарт-карта, 43 
структура, 951 
тенденции, 981 
типы, 41 

опережающая подкачка страниц, 254 
опережающее чтение, 824 
блока, 473 

описатель виртуальной памяти, 896 
опрос, 322 

оптимальный алгоритм замещения 
страниц, 246 
оптимизация 

общий случай, 975 
по памяти, 970 
по скорости, 970 
оптический диск, 344 
опыт, роль в управлении проектом, 979 
Оранжевая книга, 349, 722 
организация 

дискового пространства, 456 
файла, 458 

органный алгоритм, 541 
ориентированный ациклический граф, 454 
ортогональность, 956 
основной описатель тома, 478 
отказ в обслуживании, 643 
открытый текст, 646 
отложенный вызов процедуры, 858 
относительное имя пути, 441,804 
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относительный путь, 804 
отображаемый на память ввод-вывод, 308 
отображение файла на адресное 
пространство памяти, 436, 782 
отпечатки пальцев, 665 
ошибка из-за отсутствия страницы, 235 

п 

пакет, 584 

запроса ввода-вывода, 907 
пакетная обработка, 29 
пакетный режим, 313 
память, 47 
Панацеи нет, 981 
Панацея, отсутствие, 981 
папка, 438 
парадигма 

алгоритмическая, 946 
данных, 946 

интерфейса пользователя, 945 
исполнения, 945 
управления событиями, 946 
параллельные и распределенные 
системы, 983 
пароль, 651 

одноразовый, 658 

первым пришел — первым обслужен, 164 
перевоплощение, 928 
передача сообщений, 146 

производитель и потребитель, 147 
разработка систем, 146 
перезапуск прерванной команды 
процессора, 278 
переключение 

банков памяти, 895 
контекста, 52, 168 
процессов, 168 
перекос 

головок, 354 
цилиндров, 354 
перекрывающийся поиск, 337 
переменная состояния, 142,765 
перемещение программ в памяти, 224 
перенаправление, ввод-вывод, 67 
переносимый компилятор языка С, 739 
перечень возможностей, 713 
периодический процесс, 173 
персистентность, 424 
песочница, 700 
Петерсона алгоритм, 132 
ПЗУ, 49 

пиксел, 385,512 
пит, 344 
планирование 
ВМЗ, 522 

без переключений, 160 
неприоритетное, 160 


планирование ( продолжение) 
перемещения головок, 357 
алгоритм ЗЗР, 358 
элеваторный алгоритм, 359 
потоков, 175 
приоритетное, 160 
процессов, 157 
мультимедиа, 519 
реального времени, 520 
с несколькими очередями, 170 
с переключениями, 160 
планирование с постоянной скоростью, 522 
планировщик, 157 
памяти, 166 

планируемая система, 173 
повторное использование, 965 
идей, 67 

подгружаемый модуль, 800 
подкачка, 32 

страниц, ѴѴіпсІоѵѵз 2000, 898 
подключ, реестр, 849 
подписание программ, 704 
подсистема окружения, 869 
подсказка, 974 
подтверждение, 147,612 
позднее связывание, 959 
позиционно-независимый код, 894 
поиск файла по имени, 921 
поклеточная разбивка, 287 
поле, видео, 512 
политика 

и механизм, 88, 174, 282 
очистки страниц, 274 
планирования, 174 
пользовательский режим, 23 
порт ввода-вывода, 308 
последовательная непротиворечивость, 

601,620 

последовательный 
доступ, 430 
процесс, 97 

посредническое обеспечение, 608 
постоянное запоминающее устройство, 49 
постоянный шаг 
времени, 537 
данных, 537 
потайная дверь, 670 
поток, 106, 107 
□пих, 769 
ІІМХ, 768 
ѴѴіпсІоѵѵз 2000, 881 
всплывающий, 122 
данных, 800 
обнуления страниц, 902 
пользователь, 116 
рабочий, 113 
реализация, 116 
свопера, 900 
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поток ( продолжение ) 

смешанная реализация, 120 
упаковка, 118 
управляемый ядром, 119 
чехол, 118 
ядра, 955 

почти видео по заказу, 529 
размещение файлов, 538 
почтовый ящик, 148,877 
право доступа, 708 
преамбула, 307 
предельный регистр, 50, 224 
предотвращение 

взаимоблокировок, 206 
атака условия, 206—208 
условие отсутствия принудительной 
выгрузки ресурса, 208 
тупиков, один вид ресурсов, 203 
прерывание, 54,315 
неточное, 318 
точное, 318 

префиксный символ, 380 
приглашение, 67 
к вводу, 749 
примитив 
Р и V, 137 
гесеіѵе, 590 
зепсі, 590 
зіеер, 134 
ѵѵакеир, 134 

принудительное управление доступом, 720 
принцип наименьшего уровня привилегий, 716 
принципал, безопасность, 710 
принципы 

проектирования систем безопасности, 676 
разработки, 942 

приоритетное планирование, 160, 168 
пришпиливание страницы, 280 
приятельский алгоритм, 790 
проблема 

межпроцессного взаимодействия, 150 
обедающие философы, 150 
спящий брадобрей, 155 
читатели и писатели, 153 
обедающих философов, 150 
ограждения, 724 
ограниченного буфера, 134 
производителя и потребителя, 134 
монитор, 142 
передача сообщений, 147 
семафор, 137 
спящего брадобрея, 155 
читателей и писателей, 153 
пробуксовывание, 254 
проверка 

поведения, 694 
целостности, 694 


программное обеспечение 
ввода-вывода, 319 
СШ, 388 
ІІМХ, 793 
ѴѴІпсІоѵѵз, 388 
ѴѴіпсІоѵѵз 2000, 903 
буферизация, 320,331 
ввод, 376, 388 
вывод, 381,388 
именование, 319 
независимое от устройств, 329 
обработка ошибок, 320 
пространства пользователя, 335 
синхронное, 320 
сообщения об ошибках, 333 
терминал, 376 
уровни, 324 
таймеров, 368 
программный 

ввод-вывод, 321 
сегмент, 779 
прозрачность 

именования, 619 
местоположения, 619 
п роизводител ьность 

операционная система, 968 
файловая система, 471 
произвольный доступ, 430 
промежуточное программное обеспечение, 
608 

документное, 616 
координация, 630 

совместно используемый объект, 624 
файловая система, 617 
пропускная способность, 162 
просмотр программ, 670 
пространство 

имен объектов, ѴѴіпсІоѵѵз 2000, 867 
кортежей, 630 
протокол, 397,614,661,820 
ПОР, 625 
ІР, 614 

ТСР, 614,740,796 
ІЮР, 796 
процесс, 59, 97 
ІІМХ, 756 
ѴѴіпсІоѵѵз 2000, 873 
дочерний, 757 

межпроцессное взаимодействие, 126 
непериодический, 173 
периодический, 173 
проблемы межпроцессного 
взаимодействия, 150 
родительский, 757 
прямой доступ к памяти, 55,311,323 
псевдопараллелизм, 97 
публикация/подписка, 632 
пул-сервер, 526 
пуш-сервер, 526 
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р 

работа в сети, 982 
рабочий 
ІІЮ, 827 

каталог, 64, 441,804 
набор, 254 
поток, 113 

раздел диска, 78, 356 
разделение 

времени, 577 
пространства, 579 
процессора, 181 
размер 

блока, 335, 456 
кластера, 488 
страницы, 270, 272 
размещение файлов 
РАТ-таблица, 448 
мультимедиа, 532 
почти видео по заказу, 538 
связный список, 447 
разработка, операционные системы, 938 
рандеву, 148 
раннее связывание, 959 
распределенная 

операционная система, 38 
память совместного доступа, 275,596 
система, 558, 606 

распределенный, совместно используемый 
объект, 626 

растровая графика, 385 
растровое изображение, 394, 395 
расширение файла, 426 
расширения 
Ооііеі, 482 
Рок-Ридж, 481 
расширенная машина, 25 
расширяемая система, 954 
раунд, 548 
реализация 

процессов, 105 
сверху вниз, 961 
снизу вверх, 961 
регистр устройства, 23 
регулярный файл, 428 
редактор См. АррВгоѵѵзег 
реентерабельная программа, 329 
реентерабельность, 966 
реестр, ѴѴІпсіоѵѵв, 849 
режим 

без обработки, 377 
пользователя, 23 
разделения времени, 33 
с обработкой, 377 
супервизора, 23 
ядра, 23 


резервная копия, 462 

результативное обращение к кэш-памяти, 47 
репликация, 597 
ресурс, 185,400 

выгружаемый, 185 
невыгружаемый, 186 
получение, 186 
решетка, 584 

родительский процесс, 757 
родственное планирование, 578 
Рок-Ридж расширения, 481 
роль, 711 

С 

сбой, 467, 892 
процесса, 743 
свопер, 784 
свопинг, 225 
ІІМХ, 784 

связный список, 229 

связующее программное обеспечение, 608 
связь, 454, 804 
сеансовая семантика, 622 
сеансовый менеджер, 889 
сегмент, 284 
ВЗЗ, 780 
данных, 75, 780 
стека, 75 
сегментация, 283 
МШТІСЗ, 287 
Репііит, 291 
реализация, 287 

секретность благодаря неизвестности, 646 
селектор, Репііит, 292 
семантика совместного использования 
файлов, 620 
семафор, 136 
двоичный, 138 
сервер без состояния, 821 
серверный 
процесс, 87 
суррогат, 594 
сертификат, 650 
сетевая 

служба, 612 

без установления соединения, 612 
дейтаграмм, 613 
дейтаграммная 

с подтверждениями, 613 
запросов и ответов, 613 
ориентированная на соединение, 612 
сетевое аппаратное обеспечение, 609 
сетевой 

анализатор пакетов, 655 
интерфейс, 585 
протокол, 614 
терминал, 397 
ЗИМ, 401 
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сеть 

ІЗМХ, 795 
омега, 563 
сжатие 

данных, 513 

с потерями, 514 
памяти, 227 
файлов, 922 
сигнал, 758 
тревоги, 60 
сигнатурный блок, 649 
сильносвязанная система, 558 
символ 

звездочки, 712 
канала, 751 
символьное 

связывание, 454 
устройство, 305, 327 

символьный специальный файл, 65, 428, 794 
симметричный мультипроцессор, 569 
синхронизация, 139 

мультипроцессор, 571 
синхронный вызов, 591 
система 

клиент-сервер, 953 
пакетной обработки, 29 
поддающаяся планированию, 173 
шифрования файлов, 924 
системные службы, 861 
системный 

вызов, 46, 69 

безопасность, 827, 929 
ввод-вывод, 797, 905 
пример использования, 434 
управление, 759, 763, 783, 876, 895 
файловой системы, 808,912 
список контроля доступа, 928 
сквозной 

аргумент, 952 
кзш, 473 
режим, 314 
скелет, 624 

слабосвязанная система, 558 
слово состояния процессора, 45 
служба 

имен доменов, 615 
обнаружения, 629 
смарт-карта, 43,661 
событие, ѴѴІпсІоѵѵз 2000, 879 
совместно используемые страницы, 273 
совместное использование 
пространства, 579 
файлов, 620 
создание процесса, 99 
сокет, 795 

сокрытие аппаратуры, 962 
соль, 656 


сообщения об ошибках, 333 
соразмерность, 163 
состояние 
зомби, 762 
процесса, 103 
состязания, 128 
специальный файл, 65,428,794 
блочный, 794 
символьный, 794 
спин-блокировка, 131,572 
список 

разграничительного контроля 
доступа, 927 

управления доступом, 710 
справедливое планирование, 172 
спулинг, 32, 335 

стабильное запоминающее устройство, 363 
стандарт 

ІЕЕЕ 1003.1, 741 
ЗРЕС, 514 
МРЕС, 517 
РОЗІХ, 741 
8ѴЮ, 741 

шифрования данных, 924 
стандартное устройство 
ввода, 750 
вывода, 750 

сообщений об ошибках, 750 
старение, 171,252 
старшее устройство, 794 
статические и динамические структуры, 960 
стеганография, 727 
стек протоколов, 614 
степень многозадачности, 166 
сторожевой таймер, 371 
страница, 233 

пришпиливание, 280 
страничная 

организация памяти, 232 
вопросы, 266, 276 
глобальная, 267 
локальная, 267 
моделирование, 261 
регулирование загрузки, 269 
подкачка, ІЛѵІІХ, 785 
страничное прерывание, 235 
страничный 
блок, 233 
демон, 274, 785 
каталог, 294 

страусовый алгоритм, 192 
строка 

кэша, 47 
обращений, 262 
расстояний, 264 
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структура 

команды, 978 
операционной системы, 81 
пользователя, ІЛМІХ, 766 
файла, 427 

субъект, безопасность, 710 
суперблок, 445, 811 
суперпользователь, 61,826 
суперскалярный центральный 
процессор, 45 
суррогат, 594 
сценарий оболочки, 752 
счетчик команд, 44 
сырой режим, 377 

т 

таблица 

і-узлов, 812 
открытых файлов, 813 
потоков, 116 
процессов, 59, 105 
ІЛМІХ, 766 

размещения файлов 
РАТ-16, 910 
РАТ-32, 910 
страниц, 235 

инвертированная, 243 
многоуровневая, 238 
структура, 240 
элемент, 240 
таймер, 367 
тайный канал, 724 
теговая архитектура, 713 
текстовый сегмент, 75, 779 

совместного использования, 781 
текущее виртуальное время, 256 
текущий 

каталог, 441,804 
приоритет, 883 
телевидение, цифровое, 512 
телевизионная приставка, 505 
тенденции в проектировании операционных 
систем, 981 
терминал, 373 
ПЗ-232, 374 

программное обеспечение 
ввода, 376 
вывода, 381 
сетевой, 397 
тик, 368 
тип файла, 428 
Томпсон, Кен, 35 
«тонкий» клиент, 401—403 
Торвальдс, Линус, 35 


точка 

воспроизведения, 531 
повторного анализа, 922 
точное прерывание, 318 
траектории ресурсов, 200 
трамплин, 887 

трехуровневое планирование, 165 
тройной косвенный блок, 494, 815 
троянский конь, 666,726 
труба, 758 
тупик, 61, 184 

без ресурсов, 210 
тупиковая ситуация, 61,184 

У 

угроза, 643 

узкое чередование, 544 
указатель стека, 45 
улей, реестр, 852 
умное планирование, 578 
унаследованное устройство, 58 
универсальный асинхронный 
приемопередатчик, 375 
унифицированный указатель 
информационного ресурса, 616 
уплотнение памяти, 227 
управление 

памятью, 62,218 
Упих, 789 
ІЛМІХ, 779 
ѴѴІпсІоѵѵз 2000, 890 
битовый массив, 228 
виртуальная память, 232 
вопросы разработки, 266 
вопросы реализации, 276 
свопинг, 225 
связный список, 229 
сегментация, 283 
системные вызовы, 783 
проектом, 976 
процессами в ІЛМІХ, 759 
режимом энергопотребления, 405 
аппаратный аспект, 406 
аспект операционной системы, 408 
частичное функционирование, 413 
состоянием батарей, 413 
температурным режимом, 412 
физической памятью, 900 
управляемый прерываниями 
ввод-вывод, 323 
управляющие функции 
видеомагнитофона, 526 
управляющий объект, ѴѴІпбоѵѵз 2000, 858 
упрощенный процесс, 107 
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уровень 
НАІ_, 854 

аппаратных абстракций, 854 
архитектуры системы команд, 23 
условие циклического ожидания, 189 
устойчивость, 424 
устройство ввода-вывода, 52, 305 
участок обращений, 253 
учет свободных блоков диска, 458 

Ф 

файл, 63, 424 
атрибут, 431 
дескриптор, 435 
непрерывный, 445 
операции, 432 

опережающее чтение блока, 473 
размер блока, 456 
реализация, 445 
совместное использование, 453 
специальный, 65, 428, 794 
структура, 427 
файловая система, 424, 425 
АРЗ, 622 
Вегкеіеу Разі, 815 
СЭ-ВОМ, 477 
СР/М, 483 
РАТ-16, 910 
РАТ-32, 910 
130 9660, 477 
Ипих, 817 
М5-Э05, 486 
N55, 819 
ЫТРЗ, 910 
ІІГМІХ, 802 

реализация, 811 
ІІІчІІХ Ѵ7, 493 
ѴѴІпсІоѵѵз 2000, 910 
ѴѴІпсІоѵѵз 98, 490 
архивация, 462 
вызовы \Л/іп32АРІ, 912 
дисковая квота, 460 
мультимедиа, 526 
надежность, 461 
непротиворечивость, 467 
примеры, 477 
распределенная, 617 
реализация, 444 

с журнальной структурой, І_РЗ, 475 
системные вызовы ІЛчІІХ, 808 
структура, 444 
файловое кэширование, 546 
фальшивая программа регистрации, 668 
физическая архивация, 464 
физический адрес, 51 
фиксированные разделы, 219 


фильтр, 751 

фильтрующий драйвер, 910 
флаг, 750 
флэш-ОЗУ, 49 

фонд открытого программного 
обеспечения, 742 
формальные модели защищенных 
систем, 718 

форматирование диска, 353 
Фортран, 29 
фрагментация 
внешняя, 287 
внутренняя, 271 

X 

хакер, 651 
хост, 610 

хранение страничной памяти на диске, 280 

ц 

цветность, 512 
цветовая палитра, 387 
целостность данных, 643 
центральный процессор, 44 
циклическое 

ожидание, 208 
планирование, 167 
цилиндр, 48 
Ципфа закон, 540 
цифровая подпись, 649 
цифровое видео, 512,517 

ч 

частота страничных прерываний, 265 
часы, 367 

генератор прямоугольных 
импульсов, 368 
режим одновибратора, 368 
тик, 368 

червь, Интернет, 697 
червячная маршрутизация, 585 
чередование 
диск, 544 
секторов, 356 
чередующийся набор, 341 
чересстрочная развертка, 512 
чистящий поток, 476 

ш 

шаблон, 631 
шина, 55 
ІЗА, 55 
РСІ, 56 
ЗСЗІ, 57 
115В, 57 
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широкое чередование, 544 
шифрование, 646,913 

с открытым ключом, 647, 924 
с секретным ключом, 646 
с симметричным ключом, 647 
файлов, 923 

шифрующая файловая система, 924 

шлюз вызова, 296 

шрифт, 396 

шум квантования, 510 

э 

экзоядро, 87, 952 
элеваторный алгоритм, 359 


электрически стираемое ПЗУ, 49 
элемент списка контроля доступа, 928 
элементарное действие, 136 
эмулированное прерывание, 70 
энергонезависимое ОЗУ, 366 
эффект второй системы, 980 
эхопечать, 378 

Я 

ядро 

ІІІЧІХ, 754 
ѴѴІпсІоѵге 2000, 857 
яркость, 512 
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СПЕЦИАЛИСТАМ 

книжного 

БИЗНЕСА! 


УВАЖАЕМЫЕ ГОСПОДА! 

ИЗДАТЕЛЬСКИЙ ДОМ «ПИТЕР» ПРИГЛАШАЕТ ВАС К ВЗАИМОВЫГОДНОМУ 
СОТРУДНИЧЕСТВУ. МЫ ПРЕДЛАГАЕМ ЭКСКЛЮЗИВНЫЙ АССОРТИМЕНТ 
КОМПЬЮТЕРНОЙ, МЕДИЦИНСКОЙ, ПСИХОЛОГИЧЕСКОЙ, ЭКОНОМИЧЕСКОЙ 
И ПОПУЛЯРНОЙ ЛИТЕРАТУРЫ. МЫ ГОТОВЫ РАБОТАТЬ ДЛЯ ВАС НЕ ТОЛЬКО 
В САНКТ-ПЕТЕРБУРГЕ. ЗА ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИЕЙ 
ОБРАЩАЙТЕСЬ ПО СЛЕДУЮЩИМ АДРЕСАМ: 


Россия, г. Москва 

Представительство издательства «Питер», 
м. «Калужская», ул. Бутлерова, д. 176, 
оф. 207 и 240, тел./факс: (095) 777-54-67. 
Е-таіІ: 5аІе5@рііег.тзк.ги 


Россия, г. Санкт-Петербург 

Представительство издательства «Питер», 
м. «Электросила», ул. Благодатная, д. 67в, 
тел.: (812) 327-93-37, 387-54-65. 

Е-таіІ: 5аІез@ріІег.сот 


Россия, г. Воронеж 

Представительство издательства «Питер». 

ООО «Питер-Центр», ул. Ленинградская, д. 136, 
тел.: (0732) 49 68 86. 


Украина, г. Харьков 

Представительство издательства «Питер», 
тел.: (0572) 14-96-09, факс: (0572) 28-20-04, 
28-20-05. Почтовый адрес: 61093, 
г. Харьков, а/я 9130. 

Е-таіІ: ріІег@Іепс!ег.к(іагкоѵ.иа 

Украина, г. Киев 

Филиал Харьковского представительства 
издательства «Питер», тел./факс: (044) 
490-35-68, 490-35-69. Адрес для писем: 04116, 
г. Киев-116, а/я 2. фактический адрес: 04073, 
г. Киев, пр. Красных Казаков, д. 6, корп. 1. 
Е-таіІ: о№се@ріІег-ргезз.кіеѵ.иа 

Беларусь, г. Минск 

Представительство издательства «Питер», 
тел./факс: (37517) 239-36-56. Почтовый адрес: 
220100, г. Минск, ул. Куйбышева, 75. 

ООО «Питер М», книжный магазин «Эврика». 
Е-таіІ: ріІегЬе!@ШІ.Ьу 


КАЖДОЕ ИЗ ЭТИХ ПРЕДСТАВИТЕЛЬСТВ РАБОТАЕТ 
С КЛИЕНТАМИ ПО ЕДИНОМУ СТАНДАРТУ ИЗДАТЕЛЬСКОГО ДОМА «ПИТЕР». 


Ищем зарубежных партнеров или посредников, имеющих выход на зарубежный рынок. 
^ Телефон для связи: (812) 327-93-37. 

Е-таіІ: дгідогіап@ріІег.сот 


Редакции компьютерной, психологической, экономической, юридической, медицинской, 

^ учебной и популярной (оздоровительной и психологической) литературы Издательского 
дома «Питер» приглашают к сотрудничеству авторов. 

Обращайтесь по телефонам: Санкт-Петербург — тел.: (812) 327-13-11, 

Москва - тел.: (095) 234-38-15, 777-54-67. 
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Башкортостан 

Уфа, «Азия», ул. Зенцова, д. 70 (оптовая прода¬ 
жа), маг. «Оазис», ул. Чернышевского, д. 88, 
тел./факс (3472) 50-39-00. 

Е-таіІ: а5іаи1а@и1апе1.ги 

Дальний Восток 

Владивосток, «Приморский торговый дом кни¬ 
ги», тел./факс (4232) 23-82-12. Почтовый адрес: 
690091, Владивосток, ул. Светланская, д. 43. 
Е-таіІ: ЬоокЬа5е@таіІ.ргітогуе.ги 

Хабаровск, «Мире», тел. (4212) 30-54-47, 
факс 22-73-30. Почтовый адрес: 680000, 
Хабаровск, ул. Ким-Ю-Чена, д. 21. 

Е-таіІ: розІтазІег@Ьооктігз.кИѵ. ш 

Хабаровск, «Книжный мир», тел. (4212) 32-85-51, 
факс 32-82-50. Почтовый адрес: 680000, 
Хабаровск, ул. Карла Маркса, д. 37. 

Е- таіі : розІтазІег@ѵѵогІб Ьоокз. кпі. ги 

Европейские регионы России 

Архангельск, «Дом книги», тел. (8182) 65-41-34, 
факс 65-41-34. Почтовый адрес: 163061, 
пл. Ленина, д. 3. Е-таіІ: Ьоок@а{пе1.ш 

Калининград, «Вестер», тел./факс (0112) 21 -56-28, 
21-62-07. Почтовый адрес: 236040, Калининград, 
ул. Победы, д. 6. Магазин «Книги & книжечки». 
Е-таіІ: пзЫЬкоѵа@ѵез1ег.ги; 

6Пр://ѵѵш.ѵезІег.ги 

Ростов-на-Дону, ПБОЮЛ Остроменский, 
пр. Соколова, д. 73, тел./факс (8632) 32-18-20. 
Е-таіІ: оз1гот@боп.зі1ек.пе1 

Северный Кавказ 

Ессентуки, «Россы», ул. Октябрьская, 424, 
тел ./факс (87934) 6-93-09. 

Е-таіІ: гоззу@кгт/.ш 


УВАЖАЕМЫЕ ГОСПОДА! 

КНИГИ ИЗДАТЕЛЬСКОГО ДОМА «ПИТЕР» 
ВЫ МОЖЕТЕ ПРИОБРЕСТИ 
ОПТОМ И В РОЗНИЦУ 
У НАШИХ РЕГИОНАЛЬНЫХ ПАРТНЕРОВ. 

Сибирь 

Иркутск, «ПродаЛить», тел. (3952) 59-13-70, 
факс 51-30-70. Почтовый адрес: 664031, 
Иркутск, ул. Байкальская, д. 172, а/я 1397. 
Е-таіІ: ргосіаІІІ@ігк.ги; №Ір:/.ѵѵтргосІаІі1.ігк.ги 

Иркутск, «Антей-книга», тел./факс (3952) 33-42-47, 
Почтовый адрес: 664003, Иркутск, ул. Карла 
Маркса, д. 20. Е-таіІ: ап1еу@ігк.ги 

Красноярск, «Книжный мир», тел./факс (3912) 
27-39-71. Почтовый адрес: 660049, Красноярск, 
пр. Мира, д. 86. Е-таіІ: Ьоок-ѵѵогІс1@риЫіс.кгазпе1.ги 

Нижневартовск, «Дом книги», тел. (3466) 23-27-14, 
факс 23-59-50. Почтовый адрес: 628606, 
Нижневартовск, пр. Победы, д.12. 

Е-таіІ: Ьоок@пѵаг1оѵзк.ѵѵзпе(.ги 

Новосибирск, «Топ-книга», тел. (3832) 36-10-26, 
факс 36-10-27. Почтовый адрес: 630117, 
Новосибирск, а/я 560. 

Е-таіІ: о№се@1ор-кпіда.ги; 6йр://шѵѵ.Іор-кпіда.ш 

Тюмень, «Друг», тел./факс (3452) 21-34-39, 
21-34-82. Почтовый адрес: 625019, ул. Респуб¬ 
лики, д. 211. Е-таіІ: бгид@1уитеп.ги 

Тюмень, «Фолиант», тел. (3452) 27-36-06, факс 
27-36-11. Почтовый адрес: 625039, Тюмень, 
ул. Харьковская, д. 83а. Е-таіІ: 1оІіапІ@Іуитеп.ги 

Татарстан 

Казань, «Тайс», тел. (8432) 72-34-55, факс 
72-27-82. Почтовый адрес: 420073, Казань, 
ул. Гвардейская, д. 9а. Е-таіІ: іаІ5@Ьапсогр.ш 

Урал 

Екатеринбург, магазин № 14, ул. Челюскинцев, 
д. 23, тел./факс (3432) 53-24-90. 

Е-таіІ: дѵагбіа@таіІ.иг.ги 

Екатеринбург, «Валео-книга», ул. Ключевская, д. 5, 
тел. (3432) 42-07-75, факс 42-56-00. 

Е-таіІ: ѵа!ео@еІе!.ги 


Э. ТАНЬН БАУМ 


СОВРЕМЕННЫЕ 
ОПЕРАЦИОННЫЕ СИСТЕМЫ 

2 - Е И 3 Д А Н И Е 


КНИГИ, КОШ РЫК НЕ СТАРЕЮТ! 


нлнссмнй сотни ген зсіексе 


Это г нетерпением ожидаемое, переработанное и испраалеі- тое изда ие 
всемирного бестселлера : -ключа<г в себя с ; .ед--нкя о последних дост:гк/их-х 
в области технологий операционных систем.. Книга построена на лр мерах 
и содгожит информацию, необходимую д я понимания функционирований 
современных с тера ,ионнь : х систем. 

Благодаря практическому о-•.■ту, приобретет ному при разработке нескольких 
с- ерационных систем, и -ысекому уровню ания предмета Эн,-,рю Танеьблум 
смог ясно и увлеченно рассказал» о сложных вещах. Н книге приеод.лтся множество 
емких подрсбносте;., которых нет ни в одном другом издании.. 

Особое внимание в книге уделяется: 

♦ компьютер ои безопасности, надежьос:.;, мультимедиа. ым оте,оаи.*-н-. ,:г 
■' и с: ем пт и мн^тс процессорным систем, м; 

♦ графическим и ігерфейсэм пользозате ; , многомгс-дессорн-■ ѵі ■тер-гцчо::н»м 
системам, сетевым терминалом, файловым системам компакт-дисков, и руса м; 

® управлению энергопотреблением на лэмгоі.. системам РАЮ, мягким т :ймерам, 
стабильнчм храни; ицпч, с рлеедливому и -рехуровнезому план.-по анию, 
новым ■/ гори- «ам замещения страі и и. 


















































